Application security requirements

What the control asks

Information security requirements are to be identified, specified and approved whenever applications are developed or acquired. Purpose: leave no security requirement unidentified or unaddressed when an application is built or bought. Guidance: identify and specify application security requirements, normally through risk assessment and with help from security specialists; their scope depends on the application's purpose. As applicable they include: the trust needed in entities' identities, for example through authentication (5.17, 8.2, 8.5); the kinds and classification of information the application will process; how far access to data and functions must be separated and at what level; resilience against attacks or accidental disruption, such as buffer overflow or SQL injection; legal and regulatory requirements where transactions originate, are processed, completed or stored; privacy needs of all parties; protection of confidential information; protection of data in processing, in transit and at rest; secure encryption of communications between parties; input controls such as validation and integrity checks; automated controls such as approval limits or dual approval; output controls including who may access outputs; limits on free-text fields, which can accumulate uncontrolled confidential or personal data; process-driven requirements such as transaction logging, monitoring and non-repudiation; requirements set by other controls such as interfaces to logging, monitoring or leakage detection; and error message handling. For transactional services with partners, also consider the trust each party needs in the other's identity; trust in the integrity of exchanged information and ways of detecting integrity loss (checksums, hashing, signatures); who may approve, issue or sign key transactional documents; keeping key documents confidential and intact, proving they were sent and received, and preventing repudiation such as tendering contracts; confidentiality and integrity of transactions such as orders, delivery details and receipt confirmations; how long transactions stay confidential; and insurance and other contractual needs. For electronic ordering and payment, consider confidentiality and integrity of orders; the right degree of verification of customer payment information; avoiding loss or duplication of transactions; keeping transaction details off publicly accessible storage and on internal platforms instead; and, where a trusted authority issues signatures or certificates, building security into the whole end-to-end certificate or signature process. Cryptography (8.24) can meet several of these, with regard to legal requirements (5.31 to 5.36). Other information: networked applications face fraud, contract disputes, public disclosure, incomplete transmission, misrouting, unauthorized alteration, duplication or replay, so detailed risk assessment and careful control selection, often including cryptographic authentication and secure transfer, are essential; the ISO/IEC 27034 series covers application security.

Purpose in the standard’s terms, in our words: Leaves no security requirement unidentified or unaddressed when applications are built or bought.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Application security, System and network security; Protection, Defence.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• Approved application security requirements documents for new or acquired applications, derived from risk assessment with security specialist input
• Requirement checklists covering authentication, classification, access segregation, attack resilience, legal and privacy needs, data protection, encryption, input and output controls, logging and error handling
• Additional requirements for partner transactional services covering identity trust, integrity mechanisms, approval authority and non-repudiation
• Payment and ordering application requirements covering verification, duplication prevention and storage away from public exposure
• Traceability showing requirements were tested or verified before go-live
• Procurement evaluations of acquired applications against the specified requirements

Where audits commonly find gaps

• Applications are bought on functionality alone with security requirements never specified
• Requirements are generic and not derived from any risk assessment
• Free-text fields collect personal data that nobody planned to protect
• Verbose error messages disclose internal details to users

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (14.1.2, 14.1.3) is kept in the register so an older audit file can still be traced. It serves more than one security domain, which is why a domain count taken by row understates the view.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 5.37 Documented operating procedures
• 8.18 Use of privileged utility programs
• 8.25 Secure development life cycle

Read the five attributes All 93 controls