8.26 Application security requirements

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.

Source: ISO/IEC 27002:2022, 8.26. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.