Enterprise Architecture and Privacy (CIPT: Privacy Engineering and Privacy Governance)
Overview
Enterprise Architecture (EA) is the blueprint that describes how an organization's business processes, information, applications and technology fit together to deliver its strategy. For the IAPP CIPT (Certified Information Privacy Technologist) exam, the key idea is that privacy must be built into this blueprint. It should not be bolted on after systems are deployed. This guide covers why the topic matters, what it is, how it works in practice, and how to answer exam questions on it.
1. Why Enterprise Architecture and Privacy Is Important
Privacy by Design at scale. Ann Cavoukian's Privacy by Design principles require privacy to be proactive, embedded and the default. EA is the main way an organization applies these principles across every system, not just one project at a time.
Visibility of personal data. You cannot protect data you do not know about. EA artifacts give the organization-wide visibility needed for compliance with GDPR, CCPA/CPRA, HIPAA, LGPD and similar laws. These artifacts include data inventories, data flow diagrams, application portfolios and integration maps.
Lower cost of compliance. Fixing a privacy defect in production costs far more than designing it out at the architecture stage.
Consistency and reuse. Shared privacy services can be designed once and reused by many applications. Examples include consent management, identity and access management (IAM), encryption key management, logging, and data subject request (DSR) handling.
Governance alignment. EA connects the privacy program (policies, the DPO, privacy office) to IT reality, closing the gap between legal requirements and technical implementation.
Accountability. Regulators expect evidence of data protection by design and by default (GDPR Article 25). Architecture documentation, standards and review records provide that evidence.
2. What Enterprise Architecture Is
EA describes an organization at several levels, often called architecture domains:
Business architecture. Covers strategy, capabilities, processes, organizational structure and stakeholders.
Privacy angle: which business processes use personal data, and for what purpose.
Data / information architecture. Covers data entities, data models, classification, master data, metadata, lineage and data flows.
Privacy angle: where personal and sensitive data lives, how it moves, who owns it, and how long it is kept.
Application architecture. Covers the portfolio of applications, their interactions and interfaces (APIs).
Privacy angle: which applications process personal data, and how data is shared between them and with third parties.
Technology architecture. Covers infrastructure, networks, cloud, platforms, endpoints and middleware.
Privacy angle: hosting location (data residency and cross-border transfers), encryption, segmentation and logging.
Security architecture. Often treated as a cross-cutting layer, it covers controls protecting confidentiality, integrity and availability.
Privacy angle: security is necessary but not sufficient for privacy.
Common EA frameworks you should recognize:
- TOGAF (The Open Group Architecture Framework). It uses the Architecture Development Method (ADM), an iterative cycle with phases: Preliminary, A (Architecture Vision), B (Business), C (Information Systems: Data and Application), D (Technology), E (Opportunities and Solutions), F (Migration Planning), G (Implementation Governance) and H (Architecture Change Management), with Requirements Management at the center. Privacy requirements should enter at the Preliminary phase and Phase A, and be managed throughout.
- Zachman Framework. A 6x6 matrix (What, How, Where, Who, When, Why against perspectives from Planner to Worker). It is useful for asking privacy questions such as what data, where stored, and who accesses it.
- SABSA (Sherwood Applied Business Security Architecture). A business-driven security architecture framework, often paired with TOGAF.
- FEAF / DoDAF. Government frameworks.
- NIST Privacy Framework. Its functions are Identify-P, Govern-P, Control-P, Communicate-P and Protect-P. It is not an EA framework, but it maps well to architecture activities and to the NIST Cybersecurity Framework.
- ISO/IEC 27701 (privacy information management) and ISO/IEC 29100 (privacy framework). These supply privacy principles and controls that architecture can implement.
- OASIS Privacy Management Reference Model and Methodology (PMRM). A methodology for analyzing use cases, identifying privacy controls and mapping them to services and mechanisms. It is very relevant to privacy architecture.
3. How Privacy Works Within Enterprise Architecture
a) Privacy requirements as architecture requirements
Privacy principles are translated into concrete, testable requirements. Sources include the FIPPs, the OECD Guidelines, GDPR principles and ISO 29100. For example:
- Data minimization: collect only the fields necessary for the stated purpose.
- Purpose limitation: tag data with purpose metadata and enforce it at access time.
- Storage limitation: automated retention and deletion schedules.
- Individual participation: APIs to locate, export, correct and delete a person's data (DSR support).
- Security: encryption at rest and in transit, least privilege and logging.
- Transparency: just-in-time notices, privacy dashboards and consent records.
- Accountability: audit trails and evidence of controls.
b) Data inventory, mapping and classification
A core EA activity is building and maintaining a data inventory (record of processing activities, RoPA) and data flow diagrams. Classification schemes should be enforced by tooling, not just policy. Typical levels are Public, Internal, Confidential and Restricted/Sensitive, with special categories such as health, biometric and children's data.
c) Architectural privacy patterns and strategies
Jaap-Henk Hoepman's eight privacy design strategies are frequently referenced:
- Data-oriented: MINIMIZE, HIDE, SEPARATE, AGGREGATE.
- Process-oriented: INFORM, CONTROL, ENFORCE, DEMONSTRATE.
Common patterns include:
- Pseudonymization and tokenization services.
- Anonymization and aggregation layers for analytics.
- Data segregation and decentralization, which avoid a single honeypot of data.
- Attribute-based access control (ABAC) with purpose-based policies.
- Centralized consent and preference management.
- Privacy-enhancing technologies (PETs) such as differential privacy, homomorphic encryption, secure multi-party computation and federated learning.
- Edge or on-device processing to avoid central collection.
d) Centralized vs. decentralized architectures
Centralized:
- Easier governance, monitoring and DSR fulfilment.
- Higher breach impact and greater aggregation and profiling risk.
Decentralized/federated:
- Reduces aggregation risk and supports minimization.
- Harder to inventory, govern and respond to DSRs.
Exam questions often test your understanding of this trade-off.
e) Cloud, microservices and third parties
Modern EA involves SaaS, IaaS/PaaS, microservices, APIs and data lakes. Privacy considerations include:
- The shared responsibility model.
- Data residency and cross-border transfer mechanisms, such as SCCs and adequacy decisions.
- Vendor due diligence and data processing agreements.
- API gateway controls.
- Data lake governance, which prevents data lakes from becoming data swamps of unmanaged personal data.
f) Governance processes
- Architecture Review Board (ARB) / Design Authority. Privacy should be a mandatory checkpoint, with the privacy office or a privacy engineer participating.
- Privacy Impact Assessments (PIAs) / DPIAs. These are triggered during architecture and design, not after go-live. GDPR Article 35 requires a DPIA for high-risk processing.
- Privacy threat modeling. Uses LINDDUN: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Compare STRIDE for security.
- Architecture standards and reference architectures. Pre-approved building blocks with privacy controls baked in.
- SDLC integration. Privacy requirements in user stories, privacy acceptance criteria, testing and release gates.
- Change management. New data uses or integrations trigger re-assessment, matching TOGAF Phase H.
g) Roles
- Enterprise architects, solution architects, data architects and security architects.
- Privacy engineers, the DPO or privacy officer, data stewards and data owners, and business process owners.
- The privacy technologist bridges legal requirements and architecture decisions.
h) Legacy systems and technical debt
Legacy systems were often designed without privacy in mind. EA roadmaps (TOGAF Phases E and F) plan remediation. Typical options are:
- Wrapping legacy systems with access-control layers.
- Adding encryption or tokenization.
- Migrating data.
- Decommissioning systems and purging data that is no longer needed.
4. Worked Example
A retailer plans a new customer data platform (CDP). A privacy-aware EA approach would proceed as follows:
1. Business architecture: define purposes (personalization, fraud detection) and lawful bases.
2. Data architecture: map sources, classify data, define retention, and segregate sensitive categories.
3. Application architecture: integrate the consent management platform so that only consented data enters marketing use, and expose DSR APIs.
4. Technology architecture: choose a cloud region that meets residency needs, encrypt data with customer-managed keys, and pseudonymize identifiers for analytics.
5. Governance: run a DPIA, obtain ARB approval with privacy sign-off, set monitoring and audit logging, and schedule periodic reviews.
5. Exam Tips: Answering Questions on Enterprise Architecture and Privacy
Tip 1: Choose the earliest, most proactive option. If an answer embeds privacy at the architecture or design phase rather than remediating later, it is usually correct. Look for phrases like during requirements gathering, architecture vision or before development.
Tip 2: Know your data first. When asked what to do first in an EA or privacy initiative, the answer is very often a data inventory or data mapping exercise. You cannot assess risk without knowing what data exists and where it flows.
Tip 3: Distinguish privacy from security. Encryption and access control address security, which supports privacy. They do not satisfy purpose limitation, transparency, minimization or individual rights. If a question asks for a privacy control, prefer minimization, purpose binding, consent, retention or de-identification over pure security controls.
Tip 4: Prefer minimization and de-identification over protection. The strongest privacy control is not collecting or not retaining data. Hoepman's MINIMIZE strategy is first for a reason.
Tip 5: Recognize frameworks by their key words.
- TOGAF: ADM, phases, Architecture Repository.
- Zachman: matrix, interrogatives (what/how/where/who/when/why).
- SABSA: business-driven security.
- NIST Privacy Framework: Identify-P, Govern-P and the other functions.
- LINDDUN: privacy threat modeling.
- PMRM: privacy use-case analysis.
Tip 6: Understand trade-offs. Scenario questions may ask which architecture best balances utility and privacy. Weigh centralized against federated, cloud against on-premises, and raw data against aggregated or pseudonymized data. Pick the option that achieves the business purpose with the least privacy risk.
Tip 7: Governance mechanisms matter. Questions about ensuring privacy is consistently considered across projects usually point to:
- Mandatory privacy review in the Architecture Review Board.
- Reusable reference architectures.
- PIA/DPIA triggers built into the SDLC.
Tip 8: Watch for cross-border and third-party clues. If a scenario mentions cloud regions, vendors or global subsidiaries, the expected answer likely involves data residency, transfer mechanisms, processor contracts or vendor assessments.
Tip 9: Read for the role. CIPT asks you to think as a technologist. The best answer is usually a concrete technical or architectural measure, not purely legal advice. Still, it must align with legal principles.
Tip 10: Eliminate absolutes and afterthoughts. Be wary of answers containing always, never, only after deployment, or the security team alone. Privacy in EA is cross-functional and continuous.
Tip 11: Remember lifecycle thinking. Architecture must address the full data lifecycle: collection, use, storage, sharing, retention and destruction. Answers that cover disposal and retention often beat ones focused only on collection.
Tip 12: Legacy scenarios. For legacy systems lacking privacy controls, the best answer is usually a risk-based roadmap. Compensating controls (wrappers, tokenization, access restriction) bridge the gap until remediation or decommissioning is possible.
6. Quick Review Checklist
- EA covers business, data, application and technology domains, with security and privacy as cross-cutting concerns.
- Privacy enters EA as requirements derived from principles (FIPPs, OECD, GDPR, ISO 29100).
- Data inventory, mapping and classification are foundational.
- Hoepman's eight strategies and PETs are the main privacy architecture tools.
- LINDDUN is used for privacy threat modeling; DPIAs are run at the design stage.
- ARB privacy checkpoints and reference architectures drive consistency.
- Weigh centralized vs. decentralized, cloud and transfer issues, and legacy remediation.
- In exams, favor proactive, minimizing, design-stage, cross-functional, lifecycle-aware answers.
Mastering this topic means seeing privacy as a design property of the whole enterprise, not a feature of a single system. That mindset is exactly what CIPT exam questions reward.
