What does control A.3.28 require?
Information security requirements related to PII processing shall be identified, specified and approved when developing or acquiring applications.
This control sits within the Shared security controls annex (A.3) and requires a structured approach to defining security requirements for applications that handle PII. This applies equally to applications built in-house and those acquired from third parties. The key word is “approved” — security requirements must not only be identified and documented but formally signed off before development or procurement proceeds.
What does the Annex B implementation guidance say?
Annex B (section B.3.28) provides the following guidance:
- Encryption for untrusted networks — The organisation should ensure that PII transmitted over untrusted data transmission networks is encrypted for transmission
- Definition of untrusted networks — Untrusted networks can include the public internet and other facilities outside the operational control of the organisation
- Practical limitations — In some cases (e.g. the exchange of email), the inherent characteristics of untrusted data transmission network systems can require that some header or traffic data be exposed for effective transmission
- See also A.3.29: Secure System Architecture and Engineering Principles for related requirements
- See also A.3.30: Outsourced Development for related requirements
The guidance focuses specifically on encryption in transit as a baseline application security requirement. This reflects the reality that applications processing PII almost always transmit data over networks, and encryption is the fundamental protection against interception. The acknowledgement of practical limitations (such as email headers) shows a pragmatic approach — the standard recognises that not all data can be encrypted in all circumstances.
How does this map to GDPR?
Control A.3.28 maps to the following GDPR articles:
- Article 5(1)(f) — The integrity and confidentiality principle, requiring appropriate security of personal data
- Article 32(1)(a) — The requirement to implement appropriate technical and organisational measures including encryption of personal data
Both articles support the principle that applications handling personal data must have appropriate security measures designed in from the start, not added as afterthoughts.
For the full GDPR-to-ISO 27701 mapping, see GDPR Compliance Guide.
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 Clauses 6.11.1.2 (securing application services on public networks) and 6.11.1.3 (protecting application services transactions). The 2025 edition consolidates these into A.3.28 with a broader scope covering all application security requirements, not just public network and transaction security. See the Annex F correspondence table for the full mapping.
Start your free trial
Want to explore?
Sign up for your free trial today and get hands on with all the compliance features that ISMS.online has to offer
What evidence do auditors expect?
When assessing compliance with A.3.28, auditors will typically look for:
- Security requirements specification — Documented security requirements for each application that processes PII, covering authentication, authorisation, encryption, input validation, logging and data handling
- Approval records — Evidence that security requirements have been formally reviewed and approved by an appropriate authority (e.g. security team, DPO or architecture review board) before development or procurement
- Encryption in transit — Evidence that all applications transmitting PII over untrusted networks use TLS 1.2 or higher, with certificates properly configured
- Procurement security assessment — For acquired applications, evidence that PII security requirements were included in the procurement criteria and that the selected product meets them
- Security testing — Evidence that applications have been tested against their security requirements, including penetration testing or security code review results
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.27 Secure development life cycle | Application security requirements feed into the secure development process |
| A.3.26 Use of cryptography | Cryptographic requirements for applications are governed by the cryptography policy |
| A.3.23 Secure authentication | Authentication is a key application security requirement |
| A.3.10 Supplier agreements | Acquired applications must meet security requirements specified in supplier agreements |
| A.3.25 Logging | Application logging requirements should be defined as part of the security specification |
Who does this control apply to?
A.3.28 is a shared control that applies to both PII controllers and PII processors. Any organisation that develops or acquires applications for PII processing must identify and approve security requirements before proceeding. This includes web applications, mobile applications, APIs, internal tools, SaaS products and any other software that handles personal data.
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 application security management?
ISMS.online provides practical tools for managing application security requirements:
- Requirements templates — Pre-built security requirements templates for common application types, customisable to your organisation’s specific PII processing needs
- Approval workflows — Route security requirements through formal review and approval processes with audit trail and sign-off tracking
- Supplier assessment — Assess third-party applications against your security requirements using structured questionnaires and scoring
- Risk assessments — Run application-level risk assessments that feed directly into your security requirements, ensuring requirements are proportionate to the risk
- Evidence management — Store security testing results, approval records and compliance evidence in a structured, audit-ready format linked to each application
FAQs
What security requirements should be specified for PII-processing applications?
At minimum, applications processing PII should have requirements covering: authentication and authorisation (who can access PII and at what level), encryption at rest and in transit, input validation and output encoding (to prevent injection attacks), session management, logging and audit trails, error handling (to prevent PII leakage in error messages), data retention and deletion capabilities, and consent management where applicable. Requirements should be proportionate to the sensitivity of the PII and the risk profile of the application.
How does this control apply to SaaS procurement?
When acquiring SaaS applications that will process PII, the organisation should include PII security requirements in the procurement evaluation criteria. This includes assessing the vendor’s encryption practices, authentication options, data residency, access controls, logging capabilities and compliance certifications. The assessment should be documented and approved before the procurement decision is made. Ongoing compliance should be monitored through supplier management processes (A.3.10 Supplier Agreements).
What is meant by untrusted networks?
Untrusted networks include the public internet and any network facilities outside the direct operational control of the organisation. This can include third-party network providers, public Wi-Fi, mobile data networks and inter-site connections that traverse public infrastructure. For PII, the safe assumption is to treat any network outside your organisation’s direct physical and logical control as untrusted and to encrypt all PII transmissions accordingly.
