ISO/IEC 27034 Series: ISO/IEC 27034 Series – Tutorial (about 60 minutes)

The ISO/IEC 27034 series is the international guidance on application security: how an organisation builds security into the way it specifies, develops or buys, runs and retires its software applications, and how it shows that each application is as secure as it needs to be. Security architects, development and DevSecOps leads, product owners, quality and compliance staff and auditors use it to design a repeatable, evidence-based approach instead of one-off security fixes. After this tutorial you will be able to explain its central ideas – the organisation normative framework, the application normative framework, application security controls and levels of trust – and plan how a real team would apply them to one application.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ISO/IEC 27034 is a multi-part series published jointly by ISO and IEC through subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection), under the common title "Information technology – Security techniques – Application security". The published parts are: Part 1, Overview and concepts (ISO/IEC 27034-1:2011, first edition, with a technical corrigendum issued in 2014 and confirmed at systematic review in 2022); Part 2, Organization normative framework (ISO/IEC 27034-2:2015, confirmed in 2021); Part 3, Application security management process (ISO/IEC 27034-3:2018); Part 5, Protocols and application security controls data structure (ISO/IEC 27034-5:2017, confirmed in 2023); Part 5-1, XML schemas (ISO/IEC TS 27034-5-1:2018, a technical specification); Part 6, Case studies (ISO/IEC 27034-6:2016, confirmed in 2022); and Part 7, Assurance prediction framework (ISO/IEC 27034-7:2018, confirmed in 2023). A Part 4 on application security validation reached the draft stage, but its development was stopped and it was never published. A project to revise the series began in 2024, was stopped and restarted as a preliminary work item (PWI) in 2025 and, according to the ISO27k reference site, the committee agreed at a PWI meeting on 30 September 2026 to terminate that preliminary item, so the editions above remain current and no revision project is active. All parts are guidance or supporting specifications; none is a certifiable management system standard. Verified 2026-10-29 from the ISO27k reference pages on each part (the ISO catalogue blocked direct automated access, so check iso.org for any later change).

Who this is for: people who are new to structured application security. That includes software engineers and testers who keep hearing "secure development lifecycle" without a clear model behind it, product and project managers who own an application, security and risk officers who must show auditors how application risks are controlled, and procurement or vendor managers who buy or outsource software.

Prerequisites: none. A rough idea of how software is developed (requirements, design, coding, testing, release) will help, and every security term is explained when it first appears. This course paraphrases the standards in plain language; anyone implementing them should obtain the official texts from ISO, IEC or a national standards body, because standards text is copyrighted.

By the end of this tutorial:

You will be able to explain why the series treats application security as a managed process rather than a property you test once.
You will be able to use its core vocabulary correctly, including application security scope, ONF, ANF, application security control, level of trust and verification measurement.
You will be able to describe what each published part of the series covers and which part to open for a given question.
You will be able to walk through the steps of the application security management process for one application.
You will be able to explain how an application's achieved level of trust is checked, and why there is no ISO/IEC 27034 certificate.
You will be able to follow a realistic organisation as it applies the series, from setting up its framework to a later software update.
You will be able to compare the series with ISO/IEC 27001 and 27002, NIST's Secure Software Development Framework, OWASP SAMM and ASVS and IEC 62443-4-1.

Lesson 1 – Origins, purpose and scope

Why applications need their own security approach

Most attacks that reach business data now pass through an application: a web portal with a flaw in its input handling, a mobile app that stores tokens carelessly, an internal tool that nobody patched, or a third-party library with a known weakness. Network firewalls and endpoint tools help, but they cannot fix a design decision that lets one customer read another customer's records. Security has to be part of how the application itself is specified, built, configured and operated.

Many organisations try to achieve this with a final security test just before release. That approach tends to fail in predictable ways. Flaws found at the end are expensive to fix, so they are often accepted under deadline pressure. Different teams use different checklists, so two applications that handle the same sensitive data end up with very different protection. Nobody can say afterwards which security activities were actually performed, by whom, or how well. And when the application is changed a year later, the whole question starts again from zero.

What the series sets out to do

ISO/IEC 27034 answers these problems with three main ideas. First, the organisation should collect its application security knowledge – policies, regulations it must follow, approved technologies, roles, and reusable security measures – into one managed body of practice instead of leaving it in individual heads. Second, every application should get a deliberate, risk-based decision about how much security it needs, and that decision should drive which security measures are applied to it. Third, each measure should come with a way to check that it was really done, so that the organisation can produce evidence rather than opinions.

The series describes application security as a process: a way of applying controls and checks to manage the risk of using an application, throughout its life. This is a deliberate contrast with seeing security as a state the software is in on one particular day. An application that was secure enough at launch can become unacceptable after a new regulation, a new threat or a careless change; the process is what keeps it under control.

What counts as an "application"

The scope is broader than the source code. The series considers the software together with the data it processes, the business processes it supports, the people who use and administer it, and the technology it runs on. It applies to applications developed in-house, acquired from a supplier, outsourced to a development partner, or obtained as a service, and to every stage from the first idea to final retirement. It is also independent of the development method: the same concepts can be used with a waterfall plan, an agile team or a continuous delivery pipeline.

What the series does not do is just as important. It does not list specific technical defences such as particular encryption algorithms or coding rules, and it does not replace an organisation-wide information security management system. It provides the framework into which such specific measures are placed, together with the reasoning for choosing them.

A short history

Part 1 was published in 2011 as the opening part of an international series devoted entirely to application security. Further parts followed between 2015 and 2018, each filling in one element of the framework introduced in Part 1: the organisation-wide framework, the per-application process, the formal structure of security controls, case studies and assurance predictions. Since then, the parts that have been through periodic review were confirmed unchanged rather than rewritten, which tells you that the core model has stayed stable while the techniques used inside it (static analysis, software composition analysis, cloud configuration scanning) have changed a great deal.

Lesson 2 – Key concepts and vocabulary

The series introduces a compact vocabulary. Learning these terms well is most of the work, because the rest of the standard is about how they connect. The definitions below are paraphrases, not the official wording.

Application – an IT solution, including its software, data and procedures, designed to help users carry out business processes; it may be built, bought, outsourced or used as a service.
Application security – the protection of the information an application handles, achieved by applying controls and verification throughout the application's life cycle in proportion to the risk.
Application security scope – the boundary of what must be considered for one application: its business, regulatory and technological contexts, its specifications, the data it handles and the people and processes around it.
Organization normative framework (ONF) – the organisation-wide repository of everything it has recognised as good application security practice: policies, contexts, roles, processes, reference models and a library of security controls.
Application normative framework (ANF) – the subset of the ONF that applies to one specific application, selected to reach that application's targeted level of trust; it is kept with the application for its whole life.
Application security control (ASC) – a reusable, documented package that pairs a security activity (what must be done, by whom, at which stage) with a verification measurement (how to prove it was done well).
Security activity – the action inside an ASC that reduces risk, such as performing a threat model, validating input, or reviewing third-party components.
Verification measurement – the check inside an ASC that produces evidence that the security activity was performed correctly, such as a review record, a test result or a scan report.
Level of trust – a named position on a scale that the organisation defines itself; each level corresponds to a set of ASCs that must be in place.
Targeted level of trust – the level an application owner decides the application must reach, based on its risk analysis.
Actual level of trust – the level that verification shows the application has really achieved.
Expected level of trust – used in Part 7: the level predicted for a changed or dependent application, on the basis of an earlier verified one.
Application security management process (ASMP) – the per-application process that specifies the application's context, assesses its risks, builds its ANF, realises and operates it, and audits it.
Application security life cycle reference model (ASLCRM) – a generic model of the stages an application passes through and the roles involved, used to say when each ASC applies, independently of the organisation's actual development method.
Application owner – the person accountable for the application on behalf of the business, who accepts its risks and decides its targeted level of trust.

How the concepts fit together

The organisation builds one ONF. For each application, the owner performs a risk analysis, chooses a targeted level of trust, and a team assembles the application's ANF by taking from the ONF the ASCs tagged for that level and relevant to that application's context. During development and operation the security activities in those ASCs are carried out, and their verification measurements produce evidence. When the evidence is evaluated, the result is the actual level of trust. If actual matches targeted, the application is as secure as the owner decided it should be; if not, there is a visible, documented gap to fix or to accept formally.

Figure 1 – The organisation keeps one ONF; each application draws its own ANF from it according to a targeted level of trust, and verification shows the actual level reached.

Notice the feedback arrow at the bottom of Figure 1. When a project discovers a new kind of risk or invents a better control, that knowledge should flow back into the ONF so that the next application benefits. This is how the framework improves over time instead of freezing at the version written on day one.

A note on "trust"

The word "trust" here does not mean a feeling. A level of trust is simply a label that means "these specific controls were applied and verified". Saying that an application is at level 3 is therefore a precise, checkable statement in an organisation that uses the framework, while saying "the app is quite secure" is not. The series leaves the design of the scale to each organisation: some use three levels, some more, and the levels can be tied to data classification or business impact.

Lesson 3 – Structure of the series

The series is easiest to understand as one overview part plus several parts that each expand one element of it. You rarely need all of them at once; knowing which part answers which question saves a great deal of time.

Figure 2 – Part 1 introduces the model; the other parts expand the organisation framework, the per-application process, and the structure and use of security controls.

Part 1 – Overview and concepts

Part 1 is the entry point and the part most people read. It explains the principles, defines the vocabulary from Lesson 2, and introduces all the main components: the ONF, the ASMP, the ANF, application security controls, levels of trust, the life cycle reference model and the idea of verifying an application's actual level of trust. Its annexes show how an existing development process can be mapped onto the model, how an existing security standard can be expressed as ASCs, and how the risk management process of ISO/IEC 27005 lines up with the per-application process. If you read only one part, read this one.

Part 2 – Organization normative framework

Part 2 goes deeper into the ONF: what it contains, how its supporting processes are organised and depend on each other, and how to design, implement, operate and audit it. It includes guidance on aligning the ONF with the system and software life cycle standards ISO/IEC/IEEE 15288 and 12207, and an example of introducing an ONF in an existing organisation. Commentators note that Part 2 describes a fairly formal arrangement, with a body that owns and oversees the framework, which suits organisations that already run structured processes.

Part 3 – Application security management process

Part 3 describes the ASMP in detail: its steps, what goes in and out of each, and the elements of the ANF that each step creates or uses. It also gives guidance on realising and operating an application under the process. This is the part a project or product team uses most, because it turns the abstract model into a sequence of work for one application.

Part 5 and Technical Specification 5-1 – Controls as data

Part 5 defines the minimum information an ASC must carry and gives it a formal structure, together with the activities and roles of the life cycle reference model and the idea of packaging ASCs into libraries. The companion technical specification, ISO/IEC TS 27034-5-1, provides XML schemas that implement this structure, so that ASC libraries can be exchanged between tools and even between organisations. The aim is reuse: a well-written control for, say, secure session handling should be written once and applied to many applications.

Part 6 – Case studies

Part 6 shows example ASCs for specific kinds of applications, with XML examples. The examples are explanatory, not mandatory; organisations are encouraged to write their own ASCs suited to their technology and risks. Part 6 is useful when you are writing your first controls and want to see what a complete one looks like.

Part 7 – Assurance prediction framework

Part 7 deals with a practical question: if an application was verified at a given level of trust, how far can that result be relied on for a closely related situation – a patched version, or another program that depends on it for security functions – without repeating every activity? It sets minimum requirements for a documented rationale that justifies such a prediction, leading to an expected level of trust. Predictions based only on a developer's general track record, or on combining many components, are outside its scope.

What is missing

There is no published Part 4. A part on application security validation was drafted, but its development was stopped before publication, so verification is covered through the verification measurements in each ASC (Parts 1, 3 and 5) and through application security audit. Remember this when you see older articles that list Part 4 as "coming soon".

Inside the ONF

Part 1 lists the kinds of content an ONF should contain. In paraphrase, these are:

The business context: the organisation's processes, policies and practices that applications support, which shape what "secure" must mean.
The regulatory context: laws, regulations and contracts that affect applications in every jurisdiction where the organisation operates.
The technological context: the approved technologies, platforms and components, and the risks attached to them.
An application specifications repository: the functional and security requirements and specifications of applications.
Roles, responsibilities and qualifications: who does what in application security and what competence they need.
The organisation ASC library: the approved application security controls, each tagged with the levels of trust it supports.
The processes related to application security, including management of the ONF itself, risk analysis, the ASMP and audit.
The application security life cycle reference model that tells everyone where in the life of an application each control applies.

Anatomy of an application security control

Because ASCs are the working units of the series, it is worth knowing what one contains. Part 5 formalises this, but the idea is simple. An ASC has an identity and a stated objective, normally traced to a requirement in the ONF (a regulation, a policy or a technical risk). It describes a security activity: what to do, which role performs it and at what stage of the life cycle. It describes a verification measurement: how the activity is checked, who checks it and what evidence results. And it carries level-of-trust tags that say for which levels it is required. A control without a verification measurement is incomplete in this model, because there would be no way to show it had been applied.

Figure 3 – An ASC ties a risk-reducing security activity to the verification that proves it was done, labelled with the levels of trust that require it.

Lesson 4 – How it works in practice

Two loops: organisation and application

In practice the series runs as two connected loops. The organisation-level loop builds and maintains the ONF: it gathers contexts, defines the level-of-trust scale, writes and approves ASCs, assigns roles and trains people. The application-level loop, the ASMP, is repeated for every application that matters, using the ONF as its source. Outputs of the application loop – new risks, improved controls, audit findings – feed back into the organisation loop.

Setting up the ONF

A typical start is small. Someone with authority, often the chief information security officer together with engineering leadership, sets up an owner for the framework, sometimes a small committee with representatives from security, development, operations, legal and the business. The team collects the existing material that already counts as practice: the secure coding guideline, the release checklist, the penetration test procedure, the cloud baseline, the privacy rules. It then turns the most important items into ASCs, each with a verification measurement, and defines a level-of-trust scale with perhaps three or four levels. The first version does not need to be complete; it needs to be used and improved.

The application security management process

For each application, the ASMP proceeds through five steps. The step names below are paraphrased from Part 3.

Specify the application's requirements and environment. Define the application security scope: which business processes it supports, which data it handles and how sensitive that data is, which regulations apply, which technologies and suppliers are involved, and who the users and administrators are.
Assess the application's security risks. Analyse the threats and vulnerabilities in that context and their possible impact. The application owner reviews the results and decides the targeted level of trust, accepting the remaining risk at that level.
Create and maintain the ANF. Select from the ONF the ASCs required for the targeted level and relevant to the application's context, add any application-specific controls, and record the result as the application's ANF.
Realise and operate the application. Carry out the security activities of the ANF's controls at the right stages, during development or acquisition, deployment, operation, maintenance and finally retirement, and record the evidence from their verification measurements.
Audit the security of the application. Evaluate the evidence to establish the actual level of trust, compare it with the target, and report gaps to the owner for correction or formal risk acceptance.

Figure 4 – The application security management process runs from context and risk to a tailored ANF, realisation, and audit, looping back when gaps or changes appear.

The life cycle reference model in daily work

Organisations use very different development methods, so the series does not assume one. Instead the ASLCRM provides a neutral set of stages, from preparing the application through realising it (by development or acquisition), transitioning it into use, using it in production, and finally archiving and disposing of it. It also groups the people involved by their responsibilities, such as managing the application, provisioning it, operating it, managing its infrastructure and auditing it. Each ASC is attached to stages and roles in this neutral model. The organisation then maps the neutral model onto its real method once: for example "realisation" maps onto sprints and the delivery pipeline, and "transition" maps onto release and change management. After that mapping, every ASC lands automatically in the right place in the team's actual workflow.

Roles

The series assigns responsibilities rather than job titles, but some roles appear in almost every implementation. The application owner decides the targeted level of trust and accepts residual risk. Project or product managers make sure the ANF's activities are planned and resourced. Architects, developers and testers perform most security activities during realisation. Operations staff perform the activities that apply in production, such as patching, monitoring and access reviews. Auditors, who must be independent of the work they assess, evaluate the evidence. And the ONF owner keeps the framework current and resolves conflicts between teams.

Artefacts you should expect to see

A working implementation leaves a trail of concrete records: the ONF itself (often a wiki or a governance repository plus a control catalogue); a level-of-trust scale with criteria for choosing a level; an ANF for each in-scope application; risk analysis records signed off by owners; evidence from verification measurements, such as scan reports, review notes and test results; and audit reports stating actual levels of trust. In a modern pipeline much of the evidence can be generated automatically, which makes verification cheaper and more frequent.

Fitting into agile and DevOps

Nothing in the series requires heavy documentation for its own sake. A team can express ASCs as pipeline stages, definition-of-done criteria, pull request templates or infrastructure policies, as long as each one still has a stated objective, a responsible role, a moment in the life cycle and a verifiable result. The level of trust then becomes a property the pipeline can report: "this release meets all level 2 controls except one, for which the owner has accepted the risk until the next sprint".

Lesson 5 – Assessment, certification and compliance

There is no ISO/IEC 27034 certificate

Unlike ISO/IEC 27001, which contains requirements for a management system and has an accredited certification scheme, the ISO/IEC 27034 series is written as guidance and supporting specifications. There is no accredited third-party certification of an organisation "to ISO/IEC 27034". Be cautious if a supplier claims to be "ISO 27034 certified"; ask what was actually assessed, by whom, against which criteria, and what evidence exists. A meaningful claim usually takes the form "our development process was mapped to the 27034 model and an internal or independent review confirmed it", which is a self-declaration or a consultancy opinion, not an accredited certificate.

What is assessed instead: the level of trust of an application

The series has its own assurance mechanism, and it works at the level of each application. The verification measurements in each ASC produce evidence. An application security audit, performed by people independent of the work, examines whether every control required by the ANF for the targeted level was applied and verified. The result is the actual level of trust. Because the levels are defined by the organisation, the statement is meaningful inside the organisation and to customers or regulators who accept its scale, but it is not a universal rating that can be compared between companies.

A good audit asks four questions. Was the application security scope complete, or were some data flows or suppliers left out? Was the targeted level chosen by the accountable owner on the basis of a real risk analysis? Does the ANF contain every ASC required for that level, with documented reasons for any addition? And does convincing evidence exist for each verification measurement, produced at the right time by the right role?

Auditing the framework itself

Part 2 also describes auditing the ONF: checking that the framework is maintained, that its contexts reflect current laws and technologies, that its ASCs are reviewed and that projects actually use it. An ONF that exists only on paper, while teams ship applications without ANFs, is a significant finding.

Using the series to support certification against other standards

Organisations that hold or seek ISO/IEC 27001 certification often use ISO/IEC 27034 as the detailed method behind their secure development controls. ISO/IEC 27002:2022 contains controls on a secure development life cycle, application security requirements, secure architecture and engineering, secure coding, security testing and outsourced development. An ONF with an ASC library and per-application ANFs gives an ISMS auditor clear, traceable evidence that those controls are designed and operating. In this way the series contributes to a certificate without itself being the subject of one.

Assurance predictions

Part 7 adds a way to manage assurance after change. When a verified application is patched or updated, or when another program relies on it for security, the team can document a prediction rationale explaining why some earlier verification results still hold, which controls must be repeated, and what the expected level of trust is. That rationale can itself be audited. The benefit is proportionality: a small, well-understood change does not trigger a full repeat of every activity, but the decision to rely on earlier evidence is explicit and reviewable rather than assumed.

Figure 5 – The level-of-trust life of one application: from a target, through applying and verifying controls, to a verified level that later changes can rely on through a documented prediction.

Lesson 6 – Worked example

This example is fictional but typical. Harbour Lending is a mid-sized consumer finance company with about 120 engineers. It runs a customer loan portal (web and mobile), an internal underwriting tool and a dozen smaller internal applications. Part of the mobile app is built by an outsourced partner. After a penetration test found an authorisation flaw that let customers see each other's documents, the board asked for a systematic approach to application security. The security architect proposes the ISO/IEC 27034 model.

Step 1 – Build a first ONF

The CISO and the head of engineering set up an application security working group with one member each from security, platform engineering, the main product teams, operations, legal and compliance. The group's first job is collection, not invention. Legal summarises the regulatory context: consumer credit rules, data protection law, and the payment card requirements that apply because the portal takes card payments for repayments. Platform engineering documents the technological context: the approved cloud provider, container platform, programming languages and frameworks, and the identity service. The business context comes from the product owners: what the portal is for, which processes it supports and what an outage or a data leak would cost.

Next the group defines a level-of-trust scale. It chooses three levels. Level 1 applies to internal tools with no customer data; level 2 to applications handling personal data; level 3 to applications that handle personal data and money movement or credit decisions. Each level is described in plain language with selection criteria, so that owners can choose consistently.

Finally the group writes the first twenty ASCs, mostly by converting existing practices. "Threat model new features that touch authentication or authorisation" becomes an ASC with an activity for the product team during design, and a verification measurement in which the security champion confirms a reviewed threat model is linked to the feature ticket. "Scan dependencies for known vulnerabilities" becomes an ASC with a pipeline activity and a verification measurement based on the scan report attached to each release. "Object-level authorisation checks on every API endpoint" becomes an ASC with a coding activity and two measurements: automated tests for cross-tenant access and a reviewer's sign-off on the pull request. Each ASC is tagged with the levels that require it; threat modelling, for example, is required at levels 2 and 3.

Step 2 – Apply the ASMP to the loan portal

The portal's product director is its application owner. The team starts by defining the application security scope: the web front end, the mobile app (including the outsourced module), the API, the document store, the connection to the credit bureau, the payment provider and the support staff who can view customer files. The data includes identity documents, income details and payment data.

The risk analysis, run with the security architect, identifies the main threats: account takeover, broken authorisation between customers, abuse of the support console by insiders, tampering with credit decisions, and weaknesses introduced by the outsourced partner. Given the impact on customers and regulators, the owner chooses level 3 as the targeted level of trust and signs the risk record.

The team builds the portal's ANF. It takes all ASCs tagged for level 3 from the library, then adds two application-specific controls. One covers the outsourced module: the partner must deliver its own scan results and threat model for each release, and Harbour Lending's team verifies them before accepting code. The other covers the support console: access to customer files requires a recorded reason, and a monthly review samples these records. Both new controls are also proposed to the working group for inclusion in the ONF library, because other applications will need them.

Step 3 – Realise and operate

The team does not create a separate security project. Each ASC is mapped to the place where the work already happens. Threat modelling becomes part of feature refinement; authorisation tests run in the pipeline; dependency and container scans gate every release; the partner's evidence is checked in the merge process for their module; access reviews join the operations calendar. The pipeline collects evidence automatically where it can and stores it with the release record.

Step 4 – Audit and decide

Three months later the internal audit team, independent of the product team, audits the portal against its ANF. Almost every control has convincing evidence. Two gaps appear. The monthly sample of support console access was skipped once, and the partner delivered scan results for only two of three releases. The actual level of trust is therefore below level 3. The owner decides to fix the first gap immediately with a calendar reminder and an assigned deputy. For the second, the owner formally accepts the risk for one release while the contract is amended to make the partner's evidence a condition of payment. The decisions are recorded, and the next audit confirms level 3.

Step 5 – A patch, using a prediction

Later a library used for document uploads needs an urgent security update. Repeating every level-3 activity for a one-line version change would be disproportionate, while assuming nothing changed would be careless. The team writes a short prediction rationale in the style of Part 7: the change is limited to one component; the authorisation design, data flows and roles are unchanged; the dependency scan, the upload test suite and the pipeline's authorisation tests will be rerun; the threat model does not need revision. The expected level of trust is level 3, and once the rerun checks pass, the release keeps its verified level. The rationale goes into the evidence record, so an auditor can later see why the shortened verification was justified.

Step 6 – Improve the framework

After the first year the working group reviews the ONF. Lessons from the portal lead to two new ASCs and the retirement of one that nobody could verify in a useful way. The underwriting tool is brought into scope at level 3, and the internal tools are classified at level 1 with a lighter ANF. The board now receives a simple dashboard: each in-scope application, its targeted level of trust, its actual level, and any open accepted risks.

The example shows the core benefits of the series in action: consistent protection for applications with similar risks, decisions owned by the business, evidence that survives staff changes, reuse of controls across teams, and proportionate handling of change.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27034 rarely stands alone. It provides the management model for application security; other documents provide the management system around it, the risk method, the life cycle processes, or detailed technical practices and requirements. The table compares the most common neighbours.

Standard or framework	What it is	How it relates to ISO/IEC 27034
ISO/IEC 27001 and ISO/IEC 27002	Requirements for an information security management system, with a reference set of controls described in 27002, including controls on secure development and testing	The ISMS sets policy and certifies the organisation; the 27034 model supplies the detailed method and evidence behind the secure development controls
ISO/IEC 27005	Guidance on information security risk management	Part 1 maps its risk process onto the per-application process; the risk analysis in ASMP step 2 can follow it
ISO/IEC/IEEE 12207 and 15288	Software and system life cycle processes	Part 2 aligns the ONF and ASMP with these processes, so security controls attach to recognised life cycle activities
NIST SP 800-218, Secure Software Development Framework (SSDF)	A set of high-level secure development practices from the US National Institute of Standards and Technology, widely used in software supply chain requirements	SSDF practices can be written as ASCs in the ONF library; 27034 adds levels of trust and per-application verification
OWASP SAMM	An open maturity model for an organisation's software security programme	SAMM measures and improves the programme (similar to the ONF); 27034 focuses on controls and assurance for each application
OWASP ASVS	An open catalogue of verifiable security requirements for web applications, organised by verification levels	ASVS requirements are a ready source for ASCs and their verification measurements, especially for web applications
IEC 62443-4-1	Secure product development life cycle requirements for industrial automation and control system components	Covers similar ground for industrial products, with a certification route; 27034 is general-purpose guidance without one

Choosing a combination

A common pattern is to use ISO/IEC 27001 as the management system, ISO/IEC 27034 as the model for how application security is organised and evidenced, and OWASP ASVS, the SSDF or internal coding standards as sources for the content of individual ASCs. A maturity model such as SAMM can then measure how well the whole programme performs over time. The series is especially useful where an organisation must show customers or regulators, application by application, which security measures were applied and how they were verified.

The main difference between 27034 and the lighter frameworks is its emphasis on formal structure: levels of trust tied to specific controls, controls that always carry verification, and a framework that is itself governed and audited. That structure costs effort, so smaller organisations often adopt the concepts – owner-chosen levels, reusable controls with evidence – without every formal element described in Part 2.

Common pitfalls and best practices

Pitfalls

Building a huge ONF before using it. Teams spend a year writing hundreds of controls that nobody applies. Start with the controls that address your real incidents and test findings, use them on one application, then grow.
Controls without verification. An ASC that says "developers should write secure code" with no way to check it produces no evidence and no level of trust. Every control needs a measurement and a responsible role.
Letting the security team choose the level of trust. The targeted level is a business decision about acceptable risk. When security staff decide it alone, owners do not feel accountable for gaps.
Treating the level as permanent. A verified level reflects a point in time. New features, regulations, threats or suppliers can invalidate it, and the ASMP must be re-entered.
Ignoring bought and outsourced software. The scope covers acquired, outsourced and service applications too; leaving suppliers out of the ANF hides some of the largest risks.
Claiming certification. Advertising an "ISO 27034 certificate" misleads customers, because no accredited scheme exists. Describe precisely what was assessed instead.
Paperwork parallel to the real workflow. If ASC evidence is produced in a separate document after the work, it will be late, incomplete or invented. Embed controls in the tools teams already use.

Best practices

Map the reference model to your real method once. Translate life cycle stages and roles into sprints, pipelines and change processes, so every ASC lands in an existing step.
Define a small, clear level-of-trust scale. Three or four levels with plain-language selection criteria, linked to data classification, are easier to apply consistently than a fine-grained scale.
Write reusable ASCs. Make controls technology-aware but application-neutral, store them in a versioned library, and borrow content from sources such as OWASP ASVS or the SSDF.
Automate evidence collection. Pipeline scans, tests and policy checks can record verification results with each release at almost no extra cost.
Keep audits independent. The people who evaluate evidence and state the actual level of trust should not be the people who did the work.
Document change decisions. Use a prediction rationale for patches and dependent applications instead of either repeating everything or assuming nothing changed.
Feed lessons back into the ONF. Review the framework at least yearly using audit results, incidents and new controls from projects.

Summary and key takeaways

ISO/IEC 27034 is a multi-part ISO/IEC guidance series on application security; Part 1 (2011, confirmed 2022) introduces the model, and Parts 2, 3, 5, 5-1, 6 and 7 expand it. There is no Part 4.
The series treats application security as a managed process across the whole life of an application, not as a one-time test result.
The organisation normative framework (ONF) collects the organisation's application security contexts, roles, processes, reference model and control library.
Each application gets its own application normative framework (ANF), selected from the ONF according to the targeted level of trust that the application owner chooses after a risk analysis.
An application security control pairs a security activity with a verification measurement, so applying it always produces evidence.
The application security management process runs from context and risk through the ANF, realisation and operation to an audit that establishes the actual level of trust.
There is no certification to ISO/IEC 27034; assurance comes from per-application verification and audit, and the series supports ISO/IEC 27001 secure development controls.
The series works best combined with sources of concrete practices such as OWASP ASVS and the NIST SSDF, and with a lean, automated implementation in the team's real workflow.

Reflection questions

Think of one application you work on. What would its application security scope include beyond its source code, and which part of that scope is most often forgotten?
If your organisation adopted a three-level scale of trust, which criteria would you use to assign levels, and which of your applications would end up at the highest level?
Choose one security practice your team already follows. How would you rewrite it as an ASC with a clear activity, role, life cycle stage and verification measurement?
Who in your organisation should be the owner of each important application, and how would you make sure they, rather than the security team, decide the targeted level of trust?
Describe a recent change to one of your applications. Would a documented prediction rationale have been enough to keep its verified level, or should more controls have been repeated? Why?