What does control A.3.27 require?
Rules for the secure development of software and systems related to PII processing shall be established and applied.
This control sits within the Shared security controls annex (A.3) and requires organisations to integrate PII protection into the software development life cycle from the outset, rather than retrofitting privacy controls after systems are built. This is the practical implementation of the “privacy by design” principle: development teams need clear, actionable rules that guide them in building systems that protect PII by default.
What does the Annex B implementation guidance say?
Annex B (section B.3.27) provides detailed guidance on embedding privacy into development:
- PII-focused development policies — Policies for system development and design should include guidance for the organisation’s PII processing needs, based on obligations to PII principals and applicable legal requirements
- Privacy by design and by default — Policies should consider the following aspects:
- Guidance on PII protection and the implementation of the privacy principles (per ISO/IEC 29100) in the software development life cycle
- Privacy and PII protection requirements in the design phase, which can be based on the output from a privacy risk assessment or privacy impact assessment
- PII protection checkpoints within project milestones
- Required privacy and PII protection knowledge for development teams
- By default, minimise processing of PII
- See also A.3.29: Secure System Architecture and Engineering Principles for related requirements
- See also A.3.31: Test Information for related requirements
The guidance is structured around five actionable areas that development teams can integrate into their existing processes. The emphasis on minimising PII processing by default is particularly significant: systems should be designed to collect and process only the PII that is strictly necessary for the identified purpose.
How does this map to GDPR?
Control A.3.27 maps to the following GDPR article:
- Article 25(1) — Data protection by design and by default, requiring controllers to implement appropriate technical and organisational measures designed to implement data protection principles and integrate necessary safeguards into the processing, both at the time of determination of the means for processing and at the time of the processing itself
Article 25 is one of the GDPR‘s most forward-looking provisions, and A.3.27 provides a structured way to demonstrate compliance by embedding privacy requirements into development processes.
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.1 (secure development policy). The 2025 edition retains the core requirements as A.3.27 with expanded implementation guidance in B.3.27 that provides a clearer five-point framework for embedding privacy into development. See the Annex F correspondence table for the full mapping.
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.
What evidence do auditors expect?
When assessing compliance with A.3.27, auditors will typically look for:
- Secure development policy — A documented policy that includes PII-specific requirements for each phase of the development life cycle (design, development, testing, deployment, maintenance)
- Privacy impact assessments — Evidence that PIAs or DPIAs are conducted during the design phase for new systems or significant changes to systems that process PII
- PII protection checkpoints — Evidence that project milestones include privacy reviews or sign-offs, such as privacy gates in sprint reviews or release checklists
- Developer training — Records showing that development team members have been trained on PII protection requirements, privacy principles and secure coding practices
- Data minimisation evidence — Evidence that systems are designed to collect and process the minimum PII necessary, such as design documents showing which data fields were considered and why each is required
What are the related controls?
| Control | Relationship |
|---|---|
| A.1.2.6 Privacy impact assessment | PIAs feed privacy requirements into the development process |
| A.1.4.5 PII minimisation objectives | Development should implement data minimisation by default |
| A.3.28 Application security requirements | Security requirements for applications complement secure development rules |
| A.3.17 Awareness and training | Developer privacy training supports secure development practice |
| A.1.2.2 Identify and document purpose | Documented processing purposes define what PII the system should collect |
Who does this control apply to?
A.3.27 is a shared control that applies to both PII controllers and PII processors. Any organisation that develops or commissions software and systems for PII processing must establish and apply secure development rules. This includes in-house development teams, contracted developers and teams working on bespoke integrations or customisations. For outsourced development, see also control A.3.30 Outsourced Development.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
Why choose ISMS.online for secure development compliance?
ISMS.online provides practical tools for embedding privacy into your development processes:
- DPIA workflows — Built-in data protection impact assessment templates that integrate with your development pipeline, ensuring privacy requirements are captured at the design stage
- Policy management — Publish secure development policies with version control, staff acknowledgement and review scheduling
- Training management — Track developer privacy training completion, with automated reminders for overdue or expiring certifications
- Project milestone tracking — Create PII protection checkpoints within project plans, with sign-off workflows for privacy gates
- Compliance evidence — Collect and organise secure development evidence including PIAs, design reviews, code review records and testing results for audit readiness
FAQs
What does privacy by default mean in practice?
Privacy by default means that when a system is deployed or a user creates an account, the default settings should provide the highest level of privacy protection. Users should have to actively opt in to share additional data, rather than having to opt out of data collection. For example, a system should collect only the minimum PII fields required for the core function, with additional data collection disabled by default and only enabled if the user explicitly chooses to provide it.
What are PII protection checkpoints?
PII protection checkpoints are defined points in the project life cycle where privacy requirements are reviewed and verified. Examples include a privacy review during architecture design, a code review checkpoint that checks for PII handling compliance, a pre-release privacy sign-off and a post-deployment privacy verification. These checkpoints should be documented in the development process and have clear criteria for pass or fail.
Does this control apply to off-the-shelf software?
A.3.27 applies primarily to software and systems developed or commissioned by the organisation. For off-the-shelf software, the organisation should assess whether the software meets PII protection requirements during the procurement and configuration phases (see A.3.28 Application Security). However, any customisation, integration or configuration of off-the-shelf software that affects PII processing should follow the secure development rules established under A.3.27.
