What does control A.3.29 require?
Principles for engineering secure systems related to processing PII shall be established, documented, maintained and applied to any information system development activities.
This control sits within the Shared security controls annex (A.3) and goes beyond individual development projects to require organisation-wide engineering principles that guide all system development. While A.3.27 Secure Development Life Cycle covers the development life cycle and A.3.28 Application Security covers application security requirements, A.3.29 focuses on the architectural foundation: the design patterns, security principles and privacy-aware engineering standards that inform every system built or modified within the organisation.
What does the Annex B implementation guidance say?
Annex B (section B.3.29) provides the following guidance:
- Privacy by design and privacy by default — Systems or components related to the processing of PII should be designed following the principles of privacy by design and privacy by default
- Anticipate and facilitate controls — System architecture should anticipate and facilitate the implementation of relevant controls described in B.1 (for PII controllers) and B.2 (for PII processors)
- Minimise PII processing — The collection and processing of PII in those systems should be limited to what is necessary for the identified purposes of the processing
- Design for deletion — For example, an organisation that processes PII should ensure that it disposes of PII after a specified period. The system that processes that PII should be designed in a way to facilitate this deletion requirement
- See also A.3.30: Outsourced Development for related requirements
- See also A.3.31: Test Information for related requirements
The deletion example is particularly instructive: if a system is not designed to support data deletion from the outset, retrofitting this capability later can be extremely costly and technically complex. The same principle applies to data minimisation, consent management, data portability and every other privacy requirement.
How does this map to GDPR?
Control A.3.29 maps to the following GDPR article:
- Article 25(1) — Data protection by design and by default, requiring the implementation of appropriate technical and organisational measures designed to implement data protection principles effectively and integrate necessary safeguards into the processing
A.3.29 provides a practical framework for satisfying Article 25’s requirement that data protection is considered at the architectural level, not just at the application level.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered by Clause 6.11.2.5 (secure system engineering principles). The 2025 edition retains the core requirements as A.3.29, with the implementation guidance in B.3.29 providing a clearer connection to the privacy by design principles and the specific controller and processor controls that system architecture should anticipate. See the Annex F correspondence table for the full mapping.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
What evidence do auditors expect?
When assessing compliance with A.3.29, auditors will typically look for:
- Documented engineering principles — A set of documented secure system engineering principles that address PII protection, including data minimisation, purpose limitation, storage limitation and security by default
- Architecture review records — Evidence that system architectures are reviewed against the documented principles before development proceeds
- Privacy-aware design patterns — Documented design patterns or reference architectures that development teams use as templates, incorporating PII protection requirements
- Design for data lifecycle — Evidence that systems are designed to support the full PII data lifecycle, including collection, processing, storage, deletion and data subject rights
- Maintenance of principles — Records showing that engineering principles are reviewed and updated periodically or in response to changes in privacy requirements
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.27 Secure development life cycle | Development processes should implement the engineering principles |
| A.3.28 Application security requirements | Application requirements should align with the architectural principles |
| A.1.2.6 Privacy impact assessment | PIAs identify privacy risks that engineering principles should address |
| A.1.4.5 PII minimisation objectives | System architecture should enforce data minimisation by default |
| A.1.4.6 De-identification and deletion | Systems must be architecturally capable of supporting deletion requirements |
Who does this control apply to?
A.3.29 is a shared control that applies to both PII controllers and PII processors. Any organisation that develops information systems for PII processing must establish and maintain engineering principles. The control requires these principles to be applied to “any information system development activities,” meaning they are not optional guidelines but mandatory standards for all development work.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Why choose ISMS.online for secure system architecture compliance?
ISMS.online provides practical tools for managing your secure engineering principles:
- Principles register — Document and maintain your secure engineering principles in a central, versioned register that development teams can reference
- Architecture review workflows — Create review workflows that require system designs to be assessed against your engineering principles before development begins
- DPIA integration — Link privacy impact assessments to system architecture decisions, ensuring privacy risks identified in the DPIA are addressed in the design
- Compliance mapping — Map your engineering principles to ISO 27701 controls, GDPR Article 25 and other privacy framework requirements
- Review scheduling — Schedule periodic reviews of your engineering principles with automated reminders and version control
FAQs
What is the difference between A.3.27 Secure Development Life Cycle and A.3.29?
A.3.27 Secure Development Life Cycle covers the secure development life cycle — the process and procedures that development teams follow. A.3.29 covers the engineering principles — the architectural standards and design patterns that guide what systems should look like. Think of A.3.27 Secure Development Life Cycle as “how we build” and A.3.29 as “what we build towards.” Both work together: development processes (A.3.27 Secure Development Life Cycle) should enforce the application of engineering principles (A.3.29).
What are examples of secure engineering principles for PII?
Examples include: collect only the PII fields required for the stated purpose; encrypt PII at rest and in transit by default; design database schemas to support granular deletion of individual records; implement consent management at the data layer, not just the UI layer; log all PII access events; use role-based access control to restrict PII access to authorised personnel; design APIs to return only the minimum PII needed for each use case; and build data retention automation into the system from launch.
How often should engineering principles be reviewed?
Engineering principles should be reviewed at least annually and whenever there are significant changes to privacy legislation, organisational PII processing activities, technology stack or threat landscape. The review should assess whether the principles remain current, effective and aligned with the organisation’s privacy obligations. Any updates should be communicated to development teams and reflected in architecture review checklists.
