ISO/IEC 27034 Foundation cheat sheet

Application security is the discipline of building and operating software so that confidentiality, integrity and availability of the application and its data are maintained under both expected and adversarial conditions.

ISO/IEC 27034 is a multi-part standard on application security; it is not an ISMS standard like ISO/IEC 27001 but a supporting framework that adds application-specific structure and process to an existing management system.

Core vocabulary: Application Security Control (ASC) is a control defined for one or more applications; Application Security Control Library (ASCL) is the repository of ASCs; Organization Normative Framework (ONF) is the organization-wide reference framework; Application Normative Framework (ANF) is the application-specific subset.

The standard uses a risk-based, lifecycle approach: controls are selected according to the assessed security requirements and risk level of each application, not applied uniformly.

Key principles include trustworthiness of the application, traceability of controls to requirements and risks, evidence-based assurance, and reuse of proven controls across applications.

ISO/IEC 27034 is technology-agnostic and process-oriented; it complements ISO/IEC 27001/27002, ISO/IEC 27005 (risk), ISO/IEC 15408 (evaluation criteria) and ISO/IEC 12207 (software lifecycle processes).

The framework distinguishes the assessment of an application's security level from its certification; conformity claims refer to the framework's processes, not to a guarantee that the application is free of vulnerabilities.

Application security spans the whole lifecycle: requirements, design, development, verification, deployment, operation, maintenance and decommissioning, with security activities allocated to each phase.

ISO/IEC 27034 is published in multiple parts: Part 1 covers overview and concepts; Part 2 covers the organization normative framework and its processes; later parts address application security management, protocols, and use-case guidance.

Part 1 defines the concepts, the overall framework model and the relationship between the ONF, the ASCL and the ANF.

Part 2 specifies how an organization establishes, operates and maintains its ONF, including the processes for defining, validating and maintaining ASCs.

The ONF is the organization's reusable, normative reference: it contains the ASCL plus the organization's policies, roles, processes and evidence requirements for application security.

The ANF is derived from the ONF for a specific application; it records the selected ASCs, their tailoring, the security level targeted and the evidence produced.

The ASCL holds ASCs described in a consistent, structured form so they can be selected, compared and reused; each ASC typically records the control, its objective, its implementation guidance, verification method and evidence.

Framework elements include roles and responsibilities, the security-level or assurance target, the risk assessment results, the selected controls, and the evidence/records demonstrating implementation.

The framework is hierarchical: organizational level (ONF) -> application level (ANF) -> control level (ASCs), with traceability maintained between levels.

Knowledge of the exact part numbers and publication dates changes over time; treat part-level detail as version-dependent and verify against the current published edition.

An ASC is a documented control applied to an application to achieve a security objective; it is the atomic reusable unit of the ISO/IEC 27034 framework.

ASC attributes typically include: unique identifier, objective, description, source/reference, implementation guidance, verification method, expected evidence, and applicable lifecycle phase.

ASCs are categorized by lifecycle phase (requirements, design, coding, testing, deployment, operation) and by security objective (e.g., authentication, input validation, logging, cryptography, error handling).

Selection rule: an ASC is selected when it addresses an identified security requirement or risk for the application; selection is recorded in the ANF with justification.

Tailoring rule: an ASC may be adapted to the application's technology and context, but the tailoring and its rationale must be documented and the objective must still be met.

Verification of an ASC is evidence-based: the defined verification method (review, test, scan, inspection) must produce objective evidence that the control is implemented and effective.

ASCs can be reused across applications; reuse reduces effort and increases consistency, but the applicability of each ASC must be re-confirmed for the new context.

ASCs are not the same as ISO/IEC 27002 controls: 27002 controls are generic information security controls, while ASCs are application-specific and carry implementation and verification detail.

Process sequence: identify application security requirements from business, legal and risk inputs; assess risk; determine the target security/assurance level; select ASCs; implement; verify; record evidence in the ANF.

Risk assessment considers threats, vulnerabilities, likelihood and business impact for the application and its data; results drive the rigor of controls and the depth of verification.

The target security level determines how many and how strong the ASCs and the verification activities must be: higher risk requires stronger controls and more independent evidence.

Assurance is produced by evidence, not by assertion: each selected ASC must be traceable to a requirement or risk, and each implementation must be traceable to verification evidence.

Verification methods include document review, design review, code review, static and dynamic testing, penetration testing, configuration inspection and operational monitoring.

Residual risk after controls are applied must be explicitly accepted by an accountable role; acceptance is recorded as part of the application's evidence set.

Assurance activities are repeated or revisited when the application, its environment, its data sensitivity or the threat landscape changes materially.

The framework's assurance claim is about the process and the evidence trail (did we select, implement and verify the right controls?), not a certification that the software is vulnerability-free.

Adoption path: establish the ONF (policy, roles, ASCL, processes) -> pilot on one or more applications to build ANFs -> integrate into the SDLC -> scale and maintain.

Integration point rule: application security activities must be embedded in existing lifecycle gates (requirements baseline, design review, code review, release approval) rather than run as a parallel process.

Roles typically include an application security manager/owner of the ONF, application owners, developers, testers, and an independent verification or audit function.

The ASCL and ONF are living assets: they require ownership, periodic review, version control and update as technology, threats and standards evolve.

Maturity progression is incremental: start with a minimal ONF and a small set of high-value ASCs, then expand coverage and evidence rigor based on measured results.

Metrics that demonstrate program health include percentage of applications with an ANF, ASC coverage against selected requirements, verification completion rate, and open control gaps by risk.

Supplier and third-party software should be brought into the framework through contractual security requirements and evidence requests aligned with the organization's ASCs.

Common failure modes: treating the ONF as a one-time document, selecting ASCs without risk justification, collecting evidence that is not verified, and lacking an accountable owner for residual risk.

Know the definitions precisely: ASC, ASCL, ONF, ANF - exam questions often hinge on which level a described artifact belongs to.

Distinguish ISO/IEC 27034 from ISO/IEC 27001/27002: 27034 is application-security-specific and process/evidence oriented, not a certification of the application itself.

Remember the hierarchy: organization (ONF) -> application (ANF) -> control (ASC), with traceability from requirement/risk to control to evidence.

Recall that control selection is risk-driven and that tailoring is allowed only with documented rationale and preserved objective.

Assurance = evidence-based verification; a claim without recorded verification evidence is not assurance under the framework.

Implementation questions usually test lifecycle integration, roles, maintenance of the ONF/ASCL and incremental maturity rather than tool specifics.

When a question asks about a 'library' of reusable application controls, the answer is the ASCL; when it asks about an application-specific set, the answer is the ANF.

Where a question depends on a specific part number or edition date, verify against the current published ISO/IEC 27034 edition rather than memory.