Most application security programmes are a collection of tools and good intentions, with no organisation-wide definition of which security controls an application must have, how that is decided per application, or how anyone proves it was done. ISO/IEC 27034 is the international standard series that supplies that structure: an Organization Normative Framework (ONF) that holds the approved application security practices, a management process that selects controls for each application against a targeted level of trust, and a common format for describing application security controls. This guide explains each published part with its edition and status, the core concepts, the controls that matter for API keys and service credentials inside applications, and how to implement and evidence the series. It does not repeat the life-cycle practices covered in the Secure Software Development Lifecycle (SSDLC) Guide; it explains the governance model around them. It is written for application security leads, ISMS managers, architects and auditors, and describes the standards from their catalogue entries without reproducing their text.
Key takeaways
- A governance framework, not a checklist. ISO/IEC 27034 tells you how to define, select, implement and verify application security controls across an organisation; the controls themselves come from your own sources, such as OWASP ASVS.
- The ONF is the centre of gravity. It is the organisation's single repository of application security policies, processes, roles, controls and tools, and every application draws from it.
- Each application gets a targeted level of trust. Controls are selected per application according to its risk, then the application is built and verified against that target.
- It covers bought and outsourced software too. The Part 1 catalogue entry applies the series to in-house, acquired and outsourced development and operation.
- Old dates, current status. Part 1 dates from 2011 but was confirmed in 2022; Parts 3 and 5 were confirmed in 2023. Part 4 on validation was cancelled.
What it is and who it applies to
According to the ISO catalogue, ISO/IEC 27034-1 assists organisations in integrating security seamlessly throughout the life cycle of their applications, providing an overview of application security with definitions, concepts, principles and processes. It applies to applications developed internally, acquired from third parties, and where development or operation is outsourced. The series is maintained by ISO/IEC JTC 1/SC 27.
| Part | Title (short) | Edition and date | Status (checked 8 November 2026) | Source of status |
|---|---|---|---|---|
| ISO/IEC 27034-1:2011 | Overview and concepts | Edition 1, November 2011 | Confirmed 2022 (stage 90.93) | ISO catalogue |
| ISO/IEC 27034-2:2015 | Organization normative framework | Edition 1, August 2015 | Confirmed 2021; listed as under systematic review (90.20) | ISO catalogue |
| ISO/IEC 27034-3:2018 | Application security management process | Edition 1, May 2018 | Confirmed 2023 | ISO catalogue |
| ISO/IEC 27034-4 | Application security validation | Not published | Project cancelled | ISO27k summary |
| ISO/IEC 27034-5:2017 | Protocols and application security controls data structure | Edition 1, October 2017 | Confirmed 2023 (stage 90.93) | ISO catalogue |
| ISO/IEC TS 27034-5-1:2018 | Protocols and ASC data structure, XML schemas | Edition 1, 2018 (Technical Specification) | Reported confirmed 2021 | ISO27k summary |
| ISO/IEC 27034-6:2016 | Case studies | Edition 1, 2016 | Reported confirmed 2022 | ISO27k summary |
| ISO/IEC 27034-7:2018 | Assurance prediction framework | Edition 1, 2018 | Reported confirmed 2023 | ISO27k summary |
Rows marked "ISO27k summary" come from the independent iso27001security.com summary because the ISO catalogue page could not be read; confirm them on the ISO catalogue before contractual use. The independent summary also reported an update to Part 5 in draft; the ISO catalogue still shows the 2017 edition as current.
Structure and key requirements
The series separates what an organisation decides once (the ONF) from what it does for each application (the management process). The descriptions below are NHI Mgmt Group's operational interpretation of the catalogue abstracts and the ISO27k summary, not text from the standard.
| Concept | What it is | Defined in | Practical artefact |
|---|---|---|---|
| Organization Normative Framework (ONF) | The organisation-wide repository of application security policies, processes, roles, controls, tools and reference material | Part 1 (concept), Part 2 (detail and implementation) | An application security standard plus a control library, owned and versioned |
| Application Normative Framework (ANF) | The subset of the ONF that applies to one application | Parts 1 and 3 (Part 7 requires a defined ANF) | Per-application security requirements baseline |
| Targeted level of trust | The level of security an application must reach, set from its risk, similar to a security plan; the application is built to it and verified against it | Part 1 | Risk tier with its required control set |
| Application security control (ASC) | A described control with its purpose, activities, roles and verification measurement | Part 5 (minimal attributes), TS 5-1 (XML), Part 6 (examples) | Control entries in the library with a test for each |
| Application security life cycle reference model (ASLCRM) | Reference stages and roles for an application's life, onto which ASCs are mapped | Part 5 | Your SDLC stages mapped to control activities |
| Application security management process | The per-application process: specify requirements and environment, assess risk, create the ANF, provision and operate, audit | Part 3 | Intake, risk assessment, requirements, verification and sign-off records |
| Assurance prediction | Reasoning about whether controls verified in one context assure a similar application | Part 7 | Rules for reusing verification evidence across applications |
How it differs from SDLC frameworks
- NIST SSDF (SP 800-218): lists secure development practices and outcomes. ISO/IEC 27034 supplies the organisational mechanism (ONF, ANF, level of trust) to decide which practices apply to which application. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
- OWASP SAMM: measures programme maturity. ISO/IEC 27034 defines the structure that maturity is measured against. See the OWASP SAMM Guide.
- OWASP ASVS 5.0: a ready-made source of verifiable requirements with three levels, which fits naturally as ASC content in the ONF and as the basis of targeted levels of trust. See Application Security Requirements from ASVS.
Identity and NHI requirements
Applications are among the largest holders of non-human identities: database credentials, API keys for third-party services, OAuth client secrets, signing keys and cloud role assumptions. ISO/IEC 27034 is technology-neutral, but its control library is where these requirements should live, each with a verification method. OWASP ASVS 5.0 offers verifiable wording that maps well:
| ASC in the ONF | ASVS 5.0 source | Verification method |
|---|---|---|
| Document every secret the application depends on and its rotation schedule | V13.1.4 | Architecture review; secrets register per application |
| Store backend secrets in a secrets management solution such as a key vault | V13.3.1 | Secret scanning of repositories and images; configuration review |
| Least privilege for access to secret assets | V13.3.2 | Review of vault policies and cloud roles used by the application |
| Perform cryptographic operations in an isolated security module | V13.3.3 | Design review for high trust tiers |
| Secrets expire and are rotated per the documented schedule | V13.3.4 | Vault audit logs showing rotation events |
| Document all external services the application communicates with | V13.1.1 | Data flow diagram and egress review |
Use the targeted level of trust to scale these: ASVS assigns V13.3.1 to level 2 and V13.3.4 to level 3, so a low-risk internal tool and a payment API inherit different obligations from the same ONF. See the Secrets Management Guide and the Git Secret Scanning Guide.
Implementation steps
- Set scope and ownership. Name the ONF owner (usually the application security lead), the ONF committee that approves changes, and the scope: in-house, acquired, outsourced and SaaS-configured applications.
- Build the ONF. Gather existing policies, coding standards, tool configurations and requirement sources into one versioned repository. Choose a requirement source such as ASVS 5.0 as the base control library and record local additions.
- Define levels of trust. Create three or four application risk tiers from data sensitivity, exposure and business impact, and map each tier to a required control set and verification depth.
- Write control entries. For each ASC record purpose, the life-cycle stage where it applies, the role responsible and how it is verified (automated test, review, penetration test). Part 5 sets the minimal attributes; use them as fields.
- Run the per-application process on a pilot. Pick three applications of different tiers. Assess risk, set the target level, derive the ANF, implement and verify. Measure effort and fix friction before scaling.
- Integrate with delivery. Turn ANF requirements into backlog items and pipeline checks. Gate releases only where verification is automated and reliable; for others, record a review sign-off. Start gates in report-only mode and switch to blocking per tier once false positives are under control; keep a documented override with expiry for emergencies.
- Extend to suppliers. Put the relevant ANF in contracts and acceptance criteria for acquired and outsourced software. See the Application Security Policy Template.
- Audit and improve. Review ONF content annually and after major incidents or new requirement versions; feed verification failures back into training and control design.
Decision guidance
- Small teams: adopt the concepts lightly. One ONF document with an ASVS-based baseline, two trust tiers and a per-application requirements checklist is enough to meet the intent.
- Large portfolios: invest in the control library and automation. The value of Part 5's data structure is that control entries can be machine-readable and linked to tests and ASPM tooling. See the Application Security Posture Management (ASPM) Guide.
- Heavily outsourced estates: the ANF becomes a procurement document. Require suppliers to evidence verification against it rather than general secure development claims.
- Adopt 27034 or SSDF: they are complementary. Choose SSDF language where US federal software attestation applies, and use 27034 concepts to organise how controls are selected and evidenced.
Evidence and assessment
There is no ISO/IEC 27034 certificate; Part 4 on validation was cancelled. Conformance is shown through ISO/IEC 27001 audits of secure development controls, customer assessments and internal audit.
| Evidence | What an assessor checks |
|---|---|
| ONF repository with version history and approvals | Single source, owned, reviewed, change controlled |
| Trust tier definitions and application inventory with tiers | Every in-scope application has an assigned target level |
| Per-application ANF or requirements baseline | Derived from the ONF for the application's tier; deviations approved |
| Verification results per control | Test outputs, review records and penetration test findings tied to specific controls |
| Release decisions and exceptions | Sign-off against the target level; exceptions time-limited with owners |
| Supplier contracts and acceptance records | Security requirements included and verified on delivery |
Metrics
- Tier coverage: percentage of in-scope applications with an assigned level of trust and an ANF.
- Verified control rate: percentage of required controls with current verification evidence, per tier.
- Exception age: number and median age of open security exceptions against ANFs.
- Secrets hygiene: hard-coded secrets found per scan and percentage of applications with all secrets in a vault.
- Escape rate: production vulnerabilities in categories the ANF required controls for. See the AppSec Programme Metrics Guide.
Mapping to other frameworks
CSF 2.0 and SP 800-53 identifiers were checked against the official NIST datasets; ASVS IDs against the official ASVS 5.0 dataset.
| 27034 element | ISO/IEC 27001:2022 Annex A | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| ONF (policy, roles, control library) | 8.25 Secure development life cycle; 5.1 Policies for information security | GV.PO-01, PR.PS-06 | SA-3, SA-15 |
| Targeted level of trust and requirements | 8.26 Application security requirements | ID.RA-01 | SA-4, SA-8 |
| Secure architecture and design | 8.27 Secure system architecture and engineering principles | PR.PS-06 | SA-8, SA-17 |
| Implementation and coding controls | 8.28 Secure coding | PR.PS-06 | SA-15 |
| Verification | 8.29 Security testing in development and acceptance | ID.RA-01 | SA-11 |
| Outsourced and acquired applications | 8.30 Outsourced development | PR.PS-06 | SA-4 |
| Change and operation | 8.32 Change management | PR.PS-01 | CM-3 |
CIS Controls v8.1 Control 16 (Application Software Security) covers comparable safeguards. See the Application Security Guide for the wider discipline.
Common pitfalls
- An ONF that is a shelf document. Policies collected once and never connected to pipelines, tickets or supplier contracts.
- One level of trust for everything. Applying the full control set to every internal tool burns goodwill; applying the minimum to customer-facing APIs leaves risk. Tiering is the point of the model.
- Controls without verification. Control entries that state an intention but no test, so nobody can show the control is present.
- Ignoring acquired and SaaS-configured software. The catalogue scope includes acquired and outsourced applications, yet many programmes cover only code written in-house.
- Secrets left out of the control library. Hard-coded keys and unrotated credentials remain a common route to compromise, and are easy to verify with scanning once they are a required control.
- Claiming 27034 certification. No such certificate exists; marketing or contract wording that suggests one misleads customers.
Practitioner checklist
- Name an ONF owner and approval body, and keep the ONF in one versioned repository.
- Adopt a verifiable requirement source such as OWASP ASVS 5.0 as the base control library.
- Define three or four trust tiers and assign one to every in-scope application.
- Give every application security control a verification method and a responsible role.
- Derive a per-application requirements baseline from the ONF and track deviations with expiry.
- Include secrets inventory, vault storage and rotation as required controls with automated checks.
- Write ANF requirements into supplier contracts and acceptance testing.
- Confirm the edition and status of each part on the ISO catalogue before citing it.
Standards and references
- ISO: ISO/IEC 27034-1:2011 Application security, Part 1: Overview and concepts
- ISO: ISO/IEC 27034-2:2015 Application security, Part 2: Organization normative framework
- ISO: ISO/IEC 27034-3:2018 Application security, Part 3: Application security management process
- ISO: ISO/IEC 27034-5:2017 Protocols and application security controls data structure
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- ISO27k Infosec Management Standards: ISO/IEC 27034 summary
Related NHI Mgmt Group resources: Secure Software Development Lifecycle (SSDLC) Guide · Application Security Guide · NIST Secure Software Development Framework (SSDF, SP 800-218) Guide · Application Security Requirements from ASVS