Secure by Design and Privacy by Design are distinct but complementary enterprise architecture principles. Secure by Design embeds security controls such as threat modelling, secure defaults, least privilege and attack surface reduction into systems from the outset.Privacy by Design embeds privacy controls such as data minimisation,purpose limitation,Privacy by Default and data subject rights before personal data flow are established.
Executive Summary
- Both are now board-level design expectations. Privacy by Design is directly reflected in GDPR Article 25, while Secure by Design is increasingly reflected in cybersecurity risk-management, secure development and product security expectations across frameworks such as NIS2, the EU Cyber Resilience Act,ISO 27001 and CISA Secure by Design guidance.
- The cost of bolting on is significant. The cost of bolting on security and privacy controls after deployment is usually higher than addressing them during architecture and design. Early design review helps teams identify security, privacy and compliance gaps before they become expensive remediation issues. Remediating a gap in a deployed system consistently costs more than preventing it at architecture stage.
- They are distinct but deeply overlapping. SbD is focused on protecting systems from attack. PbD is focused on protecting individuals’ personal data and privacy rights. Both share common controls least privilege, encryption, access control, audit logging, and compliance evidence. Enterprise architecture must address both through a unified design discipline.
What Are Secure by Design and Privacy by Design?
Secure by Design (SbD)
SbD is an architectural approach in which security is embedded as an inherent system property from the outset not added as a control after build. Security decisions threat modelling, attack surface mapping, trust boundary definition, cryptographic design, access control architecture, and supply chain risk assessment are made during design and reflected in the system’s structure. Formalised in NIST SP 800-160 and operationalised in CISA’s Secure by Design guidance, it is now a regulatory requirement under NIS2 Article 21 and the EU Cyber Resilience Act for products with digital elements.
Privacy by Design (PbD)
PbD is the principle that privacy protections are embedded into system architecture by default not added post-launch, and not dependent on user action. GDPR Article 25 makes this a legal obligation: data controllers must implement data minimisation, pseudonymisation, and purpose limitation as design artefacts, not compliance overlays. The “by default” element requires that only personal data necessary for each specific purpose is processed by default, without the data subject doing anything. For architects, this means data flow diagrams, consent architectures, retention policies, and data subject rights workflows are design constraints from day one.
Secure by Design vs Privacy by Design: Key Differences and Shared Foundations
The table below maps SbD and PbD across seven dimensions and identifies the controls they share. Both principles require least privilege, encryption, access control, and audit logging meaning a well-designed SbD programme directly supports PbD compliance, and vice versa. The most efficient approach treats them as a unified design discipline with two distinct primary objectives.
| Dimension | Secure by Design (SbD) | Privacy by Design (PbD) |
|---|---|---|
| Primary Goal | Protect systems, networks, and data from attack and unauthorised access | Protect individuals’ personal data and privacy rights throughout the data lifecycle |
| Design Driver | Security threat modelling and attack surface reduction before code is written | Privacy risk assessment and data minimisation before personal data flows are established |
| Core Principle | Security is an inherent system property, not an add-on or retrospective patch | Privacy is a default state users must actively choose to share more, not less |
| Regulatory Basis | NIS2 Art. 21 · EU Cyber Resilience Act · CISA Secure by Design Pledge (2024) | GDPR Art. 25 · UK GDPR · HIPAA · ISO 42001 · EU AI Act requirements |
| Who Owns It | Security architecture, engineering, DevSecOps, SOC | Privacy engineering, data protection, legal, compliance, security |
| Scope | Systems, infrastructure, APIs, applications, cloud architecture, supply chain | Personal data flows, data subject rights, consent, retention, purpose limitation |
| Risk Focus | Confidentiality, integrity, and availability (CIA triad) | Data subject rights, proportionality, purpose limitation, privacy harm prevention |
Compliance Impact: Why Both Are Now Mandatory
The regulatory environment has made SbD and PbD simultaneously mandatory for most regulated enterprises. The frameworks below represent the most significant current obligations. Note: EU Cyber Resilience Act enforcement is phased from 2026; NIS2 has been in effect since October 2024.
| Framework | Risk | SbD / PbD Requirement | Practical Consequence |
|---|---|---|---|
| GDPR Art. 25 | High | Data protection by design and by default is a legal obligation for personal data processing. | Architects must demonstrate privacy controls were embedded during design. Post-hoc measures do not satisfy Art. 25. |
| GDPR Art. 32 | High | Appropriate technical and organisational security measures are required for personal data processing. | Security architecture decisions must be documented and defensible to regulators. |
| NIS2 Directive | High | Essential and important entities must implement appropriate and proportionate cybersecurity risk-management measures. | Security bolted on after deployment does not satisfy NIS2 Article 21 risk management requirements. |
| EU Cyber Resilience Act | High | Products with digital elements placed on the EU market are subject to cybersecurity requirements, with phased obligations. | Software and hardware vendors selling into the EU must demonstrate SbD compliance; enterprise buyers should verify vendor posture. |
| CISA Secure by Design Pledge | Medium | Voluntary guidance and pledge influencing secure product development and enterprise buyer expectations. | Enterprise buyers increasingly include SbD evidence in procurement due diligence and vendor assessments. |
| ISO 27001:2022 | Medium | Information security controls should be addressed across acquisition, development, maintenance, access control, supplier relationships, risk treatment and audit evidence. | Auditors assess whether security requirements were considered before build, not only after deployment. |
Security and Architecture Team Implications
The convergence of SbD and PbD obligations requires security architects, privacy engineers, and enterprise architecture teams to work from the same design stage. The following areas are most frequently overlooked:
- Threat modelling must address both security threats and privacy risks. STRIDE addresses CIA triad threats. Privacy threat modelling (LINDDUN) addresses linkability, identifiability, disclosure, and non-compliance risks. Integrating both into a single design review process produces better outcomes and generates evidence for both GDPR and NIS2 obligations simultaneously.
- Architecture decision records (ADRs) are compliance evidence. Regulators and auditors assess whether controls were designed in not only whether they exist. ADRs documenting security and privacy design choices, alternatives considered, and rationale provide direct evidence of SbD and PbD compliance at the design stage.
- Security and privacy teams belong in the same design review. Running security architecture review and DPIA as separate, sequential activities creates gaps where a security decision has unintended privacy consequences, or vice versa. Unified design gates attended by both functions are more efficient and produce fewer compliance gaps.
- Zero Trust supports both objectives simultaneously. Zero Trust principles verify explicitly, least privilege, assume breach reduce attack surface (SbD) and enforce purpose-limited data access with audit trails (PbD). Aligning Conditional Access and identity architecture with both NIST SP 800-207 and GDPR Article 25 is achievable with the same architectural decisions.
Example Use Case: Customer Data Platform
The Scenario and the Problem
A regulated financial services organisation is building a new Customer Data Platform (CDP) consolidating customer data from CRM, email, web, and mobile channels, integrated with third-party analytics and marketing automation vendors. The architecture team has proposed adding security and privacy controls after the initial build. Without SbD, the CDP will be built with broad service account access to all data across all channels and no defined trust boundaries. Without PbD, it will collect all available customer data from all sources by default, without documented purpose limitation. Neither approach would satisfy GDPR Article 25, NIS2 Article 21, or ISO 27001 controls without significant retrospective remediation.
Applying SbD and PbD from the Outset
Applying both principles at design stage, the architecture team produces: a threat model for each integration point defining trust boundaries; a DPIA identifying which data elements are genuinely necessary and documenting purpose limitation as an architectural constraint; a data access control matrix implementing least privilege per component; TLS 1.2+ and at-rest encryption as architectural defaults; Privacy by Default configuration ensuring new records are processed only for consented purposes; and an audit logging architecture generating a tamper-resistant evidence trail from day one.
SbD and PbD Hardening Checklist
Eight recommended controls for enterprise architecture programmes implementing SbD and PbD simultaneously, labelled SbD, PbD, or Both, with framework mapping:
| # | Applies To | Control / Action | Framework Relevance |
|---|---|---|---|
| 1 | SbD | Conduct threat modelling at the architecture phase before development begins. Use STRIDE or equivalent to identify threats, attack paths, and structural mitigations. | NIST SP 800-160 · NIS2 Art. 21 · ISO 27001 A.8.25 |
| 2 | PbD | Complete a DPIA at design stage for any system processing personal data at scale, with new technologies, or involving high-risk processing. | GDPR Art. 35 · UK GDPR · ISO 29134 |
| 3 | Both | Apply least privilege across all system components, user accounts, services, APIs, and integrations. No component should hold permissions beyond its defined function. | NIST SP 800-53 AC-6 · CIS Control 6 · GDPR data minimisation |
| 4 | PbD | Apply data minimisation at design stage. Collect only personal data necessary for the stated purpose. Document the purpose for each data element as an architectural constraint. | GDPR Art. 5(1)(b)(c) · HIPAA minimum necessary |
| 5 | SbD | Design with secure defaults: encryption on, unnecessary features off, and restrictive access controls out of the box. No system should require a user action to be secure. | CISA Secure by Design Pledge · EU CRA · NIST SP 800-160 |
| 6 | Both | Implement encryption in transit, TLS 1.2+, and at rest for all sensitive and personal data. Encryption is an architectural decision, not a field-level afterthought. | GDPR Art. 32 · HIPAA Security Rule · PCI-DSS Req 4 · ISO 27001 A.8.24 |
| 7 | SbD | Embed security testing in CI/CD pipelines: SAST, DAST, SCA and dependency scanning, so vulnerabilities are caught before deployment, not in production. | CISA Secure by Design · NIS2 Art. 21 · ISO 27001 A.8.29 |
| 8 | Both | Generate continuous compliance evidence: architecture decision records, threat model outputs, DPIA results, access control matrices and audit log retention records. | GDPR Art. 5(2) accountability · ISO 27001 · SOC 2 CC3 · NIS2 |
How ServQual and SUSAN Help
- ServQual supports enterprises through Cybersecurity Services, Secure by Design, Privacy by Design, Governance, Risk, Compliance and Audits, Incident Response, Managed Security, DevSecOps and security testing services
- ServQual can help organization assess Secure by Design and Privacy by Design maturity, identify architecture and compliance gaps , review security and privacy controls, support evidence preparation and improve alignment between security architecture , privacy engineering and governance teams.
- SUSAN , ServQual’s AI driven cybersecurity , privacy and GRC platform , help connect risk visibility,control evidence,remediation ownership,audit-ready reporting and Continuous Asserance.
- For Secure by Design and Privacy by Design programs , SUSAN can help teams connet : Security and privacy control evidence, Risk and compliance visibility, Remediation ownership, Governance reporting, Audit-ready evidence
References
CISA Secure by Design Guidance · NIST SP 800-160 Vol. 2 Rev. 1 · NIST SP 800-207 (Zero Trust Architecture) · NIST Privacy Framework · GDPR Article 25 · GDPR Article 32 · NIS2 Directive (EU 2022/2555) · EU Cyber Resilience Act · ISO/IEC 27001:2022 · ISO/IEC 42001:2023 · ISACA State of Privacy 2025 · Ann Cavoukian: Privacy by Design 7 Foundational Principles
"Secure by Design protects the system. Privacy by Design protects the person. Enterprise architecture needs both."
Himanshu Warulkar
Front End Engineer | ServQual
FAQ
Most frequent questions and answers
Yes the terms are interchangeable. “Secure by Design” is the terminology used in CISA’s joint guidance and EU regulatory frameworks. Both refer to the same principle: security is embedded as an inherent system property during the design phase. The CISA Secure by Design Pledge (May 2024) and NIST SP 800-160 are the primary reference documents for enterprise architects.
A threat model identifies how an attacker could exploit a system assets at risk, attack paths, and controls to reduce likelihood or impact. A Data Protection Impact Assessment (DPIA) identifies how processing of personal data could harm individuals privacy risks, lawfulness, proportionality, and controls to reduce privacy harm severity. Both artefacts share common controls access control architecture, encryption design, data retention decisions, and audit logging and should be produced by the same unified design review process where feasible.
Privacy by Default means the most privacy-protective settings are active without any data subject action required. For architects this translates to: opt-in (not opt-out) for non-essential processing; minimal data collection in intake forms and APIs by default; restrictive access control settings that require explicit override; retention periods that expire data automatically unless a specific legal basis is documented; and no third-party data sharing unless explicitly enabled by a documented lawful basis.
Evidence is demonstrated through design artefacts, not only operational controls. Key evidence includes: architecture decision records (ADRs) documenting design choices; threat model outputs with threats, mitigations, and residual risk decisions; DPIA documentation for personal data processing; data flow diagrams showing minimisation and purpose limitation; access control matrices evidencing least privilege; and audit log retention evidence. These should be maintained as living documents, updated when systems change. Regulators assess whether controls were designed in not only whether they currently exist.
Build Security and Privacy into Enterprise Architecture
Secure by Design and Privacy by Design are no longer optional architecture principles. Regulated enterprises need threat modelling, privacy impact assessment, least privilege, encryption, audit logging, evidence records and governance controls built in from the start.
ServQual helps organizations assess security and privacy architecture maturity, identify design gaps, align controls with GDPR, NIS2 and ISO 27001, and maintain audit-ready evidence. Explore SUSAN or contact ServQual to connect Secure by Design, Privacy by Design, control evidence, remediation ownership and Continuous Assurance into one structured governance view.
Disclaimer:This article is for general informational purposes only and does not constitute legal, compliance, or security advice. GDPR, NIS2, CISA, NIST, ISO, and other frameworks and trademarks are the property of their respective owners; references reflect publicly available guidance, not endorsement. Whether a specific architecture decision satisfies a regulatory requirement depends on the facts of each system, the applicable jurisdiction, and legal advice specific to your organisation. Validate all decisions against your own environment, applicable legal requirements, and current official guidance before implementation.
