Framework

ISO/IEC 27034 application security
the ONF, the ANF, and the verification cycle

ISO/IEC 27034 is the international standard for application security governance, organising the organisation-wide structure across the Organization Normative Framework, the per-application Application Normative Framework, the Application Security Controls library, the Application Security Lifecycle Reference Model, and the closed-loop Application Security Verification process. It is the operating framework the verification standard (OWASP ASVS) runs inside and the maturity model (OWASP SAMM, BSIMM) measures against.

Get Started Free

No credit card required. Free plan available forever.

ISO/IEC 27034 application security framework

ISO/IEC 27034 is the international standard for application security governance. It is published as a multi-part family (Parts 1, 2, 3, 5, 5-1, 6, and 7) and organises the organisation-wide structure for managing application security across every application a programme operates. The standard names the Organization Normative Framework (ONF) as the shared library, the Application Normative Framework (ANF) as the per-application derivation, the Application Security Controls (ASCs) as the structured catalogue of approved controls, the Application Security Lifecycle Reference Model as the operating spine, and the Application Security Verification process as the closed-loop evidence cycle.

ISO/IEC 27034 is not a published checklist of mandatory controls. It is the structural framework the organisation uses to organise the controls the programme has decided to operate. The standard sits next to OWASP ASVS, which is a per-application verification standard with three levels, and next to OWASP SAMM, which is a maturity assessment of the application security programme. ISO/IEC 27034 is the operating framework the verification standard runs inside and the maturity model measures against.

For internal AppSec teams, product security teams, security engineering teams, GRC and compliance owners, vulnerability management leads, security architects, and CISOs running an enterprise application security programme, ISO/IEC 27034 is the standard that turns per-application security work into an organisation-wide operating model with a shared library, a per-application ANF derivation, a structured lifecycle, and a verification evidence base that survives audit citation. The framework is most useful when the application portfolio outgrows ad hoc per-application binders and the security programme needs a structure that scales across teams, products, and regulatory exposures.

The parts of the standard

ISO/IEC 27034 is published as a family. Each part covers a distinct dimension of the framework; programmes adopt the parts that match their operating need rather than treating the family as a single monolithic document. The most operationally important parts for most programmes are Parts 1, 2, and 3, with Parts 5 and 5-1 becoming important once the ASC library scales.

Part 1: Overview and concepts

Names the overall ISO/IEC 27034 model: the Organization Normative Framework (ONF), the Application Normative Framework (ANF), the Application Security Lifecycle Reference Model, the Application Security Controls (ASCs), and the Application Security Verification process. Part 1 is the structural blueprint every other part of the family reads against.

Part 2: Organization normative framework

Defines the ONF: the organisation-wide reservoir of business context, regulatory context, technological context, processes, roles, responsibilities, and the canonical library of Application Security Controls. The ONF is what every individual application reads from when its ANF is provisioned; the ONF is owned at the security programme level, not at the application team level.

Part 3: Application security management process

Names the operating process for applying the ONF to a new or existing application, deriving the application context, identifying the Targeted Level of Trust, selecting the applicable Application Security Controls, and producing the per-application ANF. Part 3 is the process the application security manager runs each time the catalogue receives a new application.

Part 5 and 5-1: Protocols and ASC data structure

Defines the structured data format for Application Security Controls so they can be exchanged, catalogued, and version-controlled rather than reinvented in each ANF. Part 5 covers protocols; 5-1 covers the XML schema. The structured ASC is what lets the ONF library scale beyond a per-application binder of bespoke controls.

Part 6: Case studies

Worked examples showing the ONF and ANF in practice across different application classes (web, embedded, mobile, regulated environments). Part 6 is the bridge from the abstract framework into the operating evidence and is often the first part security teams read when adopting the standard.

Part 7: Application security assurance prediction framework

Defines the assurance prediction surface that lets the programme forecast the security posture of a new application against its ANF before development completes. Part 7 covers the predictive read; the verification process produces the operating evidence the prediction is reconciled against.

The Organization Normative Framework

The ONF is the organisation-wide reservoir of context, processes, roles, and Application Security Controls every individual application reads from. The ONF is the most distinctive ISO/IEC 27034 artefact; without it the framework collapses into per-application binders that cannot scale. The dimensions below are the structural inputs the ONF holds.

Business context

The catalogue of business contexts the organisation operates in, with the value chains, the customer-facing surfaces, the data-handling expectations, and the strategic outcomes each context is responsible for. The business context anchors the Targeted Level of Trust selection because the value of the application to the business is one input into the trust target.

Regulatory context

The catalogue of regulatory obligations the organisation operates under, broken down by jurisdiction, by industry, by data class, and by customer commitment. The regulatory context is what makes a Targeted Level of Trust survive an audit citation; an ANF that does not name the applicable regulatory controls cannot be defended against an external read.

Technological context

The catalogue of approved technologies, supported platforms, programming languages, frameworks, cloud providers, and supply-chain inputs the application is expected to use. The technological context constrains which Application Security Controls are actually feasible and which carry residual gaps the ANF must record.

Specifications, processes, roles, and responsibilities

The catalogue of process documents, role definitions, responsibility assignments, and named owners the security programme expects every application to participate in. The ONF is where the security operating model lives so individual applications inherit the rules rather than each defining its own.

Application Security Control (ASC) library

The canonical, version-controlled catalogue of Application Security Controls the organisation has approved for reuse. Each ASC is a structured record with the threat addressed, the implementation guidance, the verification approach, the cost of implementation, and the assurance level the control achieves. The library is the most distinctive ONF artefact; without a structured ASC library the framework collapses into ad hoc per-application checklists.

Application Security Lifecycle Reference Model

The reference lifecycle the application security work attaches to: preparation, requirements, design, construction, integration and testing, transition, operations, and decommissioning. The lifecycle is the spine that the ANF and the verification work read against, so the security evidence is recorded at the stage it was produced rather than reconstructed at audit week.

How the Application Normative Framework works

Each application carries its own ANF, derived from the ONF when the application is provisioned into the security programme. The ANF is the per-application operating record the verification process reads against. The mechanics below are the ones a programme has to settle before the ANF becomes useful as an operating, reporting, and audit input.

  • Each application has its own Application Normative Framework. The ANF is derived from the ONF at the moment the application is provisioned into the security programme and is updated whenever the application context, the regulatory exposure, the technology stack, or the targeted level of trust changes.
  • The ANF records the Targeted Level of Trust the application is required to achieve. The level is a programme-decision artefact that names the assurance bar the verification process is held to, derived from the business value, the regulatory exposure, the threat landscape, and the cost of failure.
  • The ANF lists the Application Security Controls applicable to this specific application, drawn from the ONF library plus any application-specific controls the context requires. The ASC selection is the operating commitment the application team and the security team both work against.
  • The ANF carries the Application Security Lifecycle plan: which lifecycle stages are in scope, which security activities apply at each stage, which roles own each activity, and what evidence each activity is expected to produce.
  • The ANF carries the Application Security Verification plan: which ASCs are verified at which lifecycle stage, by which method (automated testing, code review, manual testing, penetration testing, formal proof), and what verification evidence is acceptable as closure.
  • The ANF is a living artefact, not a one-time output. Each lifecycle transition, each significant change to the application, each regulatory shift, and each ONF revision triggers an ANF refresh; the refresh cadence is the discipline that keeps the evidence pack current rather than stale at audit week.

The application security lifecycle stages

ISO/IEC 27034 names a reference lifecycle from preparation through decommissioning. The stages are the spine the ANF and the verification work attach to so the security evidence is recorded at the stage it was produced rather than reconstructed at audit week. The stages below are the ones the standard expects every application to traverse.

Preparation

The application is introduced into the security programme. The business context, the regulatory exposure, the technology stack, the integration points, the data classes, and the customer surfaces are recorded. The Targeted Level of Trust is set. The applicable ONF entries are inherited; application-specific gaps are named.

Requirements

Functional, non-functional, and security requirements are derived from the application context and from the ASC selection in the ANF. Threat modelling produces the threat catalogue the requirements are tested against. Security requirements become explicit acceptance criteria rather than implicit assumptions.

Design

Architecture and design decisions are recorded with the security implications named. The ASC-to-design mapping is captured so verification later can trace each control to its design home. Threat modelling deepens into design-level threat coverage.

Construction

Code is written against the design with security activities (secure-code training, code review, SAST, SCA, dependency-upgrade discipline) running continuously rather than at gate. The security evidence accumulates inside the build pipeline so the verification step reads against operating evidence rather than against asserted claims.

Integration and testing

Application Security Verification runs against the ASCs at this stage. DAST, authenticated DAST, integration testing, fuzzing, manual security testing, and any required penetration testing produce the evidence the ANF verification plan expects. Findings are recorded against the ASCs they fail rather than as a generic bug list.

Transition

Release readiness is gated by the verification evidence. Open findings at the level of the Targeted Level of Trust block the release or move to a recorded exception with a named approver, scope, expiry, and compensating controls. The transition record is what the audit citation reads against later.

Operations

Continuous monitoring against the ASCs runs through the production life of the application: external scanning, authenticated DAST against production, code scanning against the active branch, dependency monitoring, security telemetry. The operations stage is the longest stage of the lifecycle and produces the bulk of the audit evidence over time.

Decommissioning

The application is retired with the security implications named: data disposal, credential revocation, integration unwiring, dependency cleanup. The decommissioning evidence closes the lifecycle record and informs the ONF where the application surfaced gaps the next application can avoid.

Application Security Verification methods

Verification runs across the lifecycle, not only at the release gate. The methods below are the ones the standard expects the ANF verification plan to select from per ASC, with the method choice driven by the nature of the control and the Targeted Level of Trust.

  • Automated scanning across the application surface: external scanning of internet-exposed endpoints, authenticated DAST against staging and production where credentials are governed, code scanning (SAST and SCA) against the connected repositories. The verification evidence records the scan configuration, the scan output, and the closure decision per finding.
  • Manual security testing: targeted penetration testing against the ASCs the ANF marks for manual verification, exploratory testing for business logic flaws automation cannot reach, configuration review of cloud and infrastructure components the application depends on.
  • Code review: peer code review against secure-coding guidelines, focused security review for changes that touch authentication, authorisation, cryptography, session handling, input validation, or sensitive data; review records become part of the verification evidence.
  • Documentary verification: design review against threat modelling output, configuration baseline review, dependency inventory review, exception register review; documentary evidence covers ASCs that are policy or process rather than runtime behaviour.
  • Third-party assessment: external penetration test reports, vendor security questionnaire responses, supplier audit results, certification evidence (where applicable) feed the verification pack for ASCs that depend on third-party security posture.
  • Compliance verification: cross-reference the ASC verification evidence against the regulatory citations the ANF named in preparation. The compliance read is parallel to the security read; the same evidence supports both when the underlying record is structured.

Evidence the framework expects

An ISO/IEC 27034 programme reads well when the evidence is produced as a side effect of the operating work rather than reconstructed at audit time. The minimum set below maps to the artefacts examiners, customer security reviewers, and audit committees most often read against, and the same artefacts feed parallel reads under OWASP ASVS, ISO 27001 Annex A.8.25 to A.8.28, SOC 2 CC7, PCI DSS 6, NIST SSDF, GDPR Article 32, and CSA CCM when the underlying record is structured.

  • Documented Organization Normative Framework covering the business context catalogue, the regulatory context catalogue, the technological context catalogue, the process and role library, the named ASC library, and the application security lifecycle reference model
  • Per-application Application Normative Framework with the application context, the Targeted Level of Trust, the selected ASCs, the lifecycle plan, and the verification plan; refreshed on every significant context change
  • Targeted Level of Trust justification per application: the inputs from business value, regulatory exposure, threat landscape, and cost of failure that produced the trust target, with named decision-maker and review cadence
  • Threat model per application aligned to the requirements and design stages, with the threat catalogue, the asset register, the trust boundaries, the attack surfaces, and the mitigations mapped to ASCs
  • Per-ASC implementation evidence covering the design decision that implements the control, the construction-stage activity that exercises it, and the test artefact that demonstrates it operating
  • Application Security Verification report per release covering the ASCs verified, the verification method per ASC, the closure decision per finding, and any exceptions raised with named approver, scope, and expiry
  • Per-finding record covering the failed ASC, the severity, the asset, the lifecycle stage at which it was found, the remediation plan, the verification evidence, and the closure decision
  • Operations-stage continuous monitoring evidence covering the scan cadence per surface, the dependency monitoring stream, the security telemetry feeding the SOC, and the recurring posture review of the production application
  • Exception register per application with each exception named against the ASC, the scope, the compensating controls, the expiry, the named approver, the rationale, and the review cadence
  • Decommissioning record per application covering data disposal, credential revocation, integration unwiring, dependency cleanup, and the ONF feedback from gaps surfaced

Failure modes the framework is designed to surface

ISO/IEC 27034 is forgiving on the choice of testing tools, the choice of build pipeline, the choice of programming languages, and the choice of cloud providers. It is unforgiving about a small number of patterns that turn the framework cosmetic rather than operational. The patterns below recur across early and mid-stage adoptions.

  • Treating ISO/IEC 27034 as a checklist rather than as a framework. The standard does not ship a list of mandatory controls; it ships a structure for organising the controls the programme has decided to operate. Programmes that try to operate ISO/IEC 27034 as a published checklist mistake the ASC library for the deliverable and produce empty binders.
  • Skipping the ONF and going straight to per-application ANFs. The ONF is what makes the framework operable at organisation scale. An ANF derived without an ONF is a bespoke binder per application with no shared library, no cross-application consistency, no programme-level governance, and no audit-readable structure. The ONF is the structural commitment the rest of the standard reads against.
  • Setting the Targeted Level of Trust as a default. The trust target is supposed to come from business value, regulatory exposure, threat landscape, and cost of failure; programmes that default every application to the same level produce inconsistent verification cost across applications and inconsistent audit reads against the actual risk distribution.
  • Operating the ASC library as a static document. The ASC library is supposed to be version-controlled, structured, and exchangeable per Part 5/5-1. Programmes that operate the library as a wiki page lose the ability to track which application has which version, which ASC has been retired, and which has been replaced.
  • Treating verification as a release-time exercise. Verification runs across the lifecycle; the integration-and-testing stage is the headline verification stage but the operations stage produces the bulk of the audit evidence over the application life. Programmes that compress verification into the release gate produce thin operations-stage evidence and surface that gap during audit walkthroughs.
  • Ignoring decommissioning. The decommissioning stage is where the application exits the programme and where the ONF receives the feedback from operating gaps. Programmes that skip decommissioning leave orphan credentials, orphan integrations, orphan data, and orphan ASC inheritance that complicates the next application onboarded.
  • Conflating ISO/IEC 27034 with OWASP ASVS. ASVS is a verification standard for individual applications with three levels and a published control set. ISO/IEC 27034 is an organisation-wide framework for application security governance including the ASC library, ANF derivation, and the application security management process. Programmes that adopt ASVS as their ISO/IEC 27034 implementation miss the ONF, the ASC library, the ANF derivation, and the application security management process.

How ISO/IEC 27034 relates to adjacent frameworks

ISO/IEC 27034 sits in a busy application security neighbourhood. The relationships below cover the frameworks programmes most often read alongside the standard. The relationships matter because programmes that operate each framework in isolation rebuild the same evidence multiple times.

ISO/IEC 27034 vs OWASP ASVS

OWASP ASVS is a verification standard for individual applications with three published levels and a structured requirement set. ISO/IEC 27034 is an organisation-wide application security governance framework. Programmes operating both adopt ASVS as the verification standard the ANF references when the application is web-shaped, and ISO/IEC 27034 as the surrounding organisation structure that derives, manages, and verifies the ANF.

ISO/IEC 27034 vs OWASP SAMM

OWASP SAMM is a maturity assessment model that scores the application security programme across 5 business functions and 15 security practices. ISO/IEC 27034 is the operating framework the maturity model assesses against. SAMM answers how mature the programme is; ISO/IEC 27034 answers how the programme is structured. The two work together: SAMM measures, ISO/IEC 27034 organises.

ISO/IEC 27034 vs BSIMM

BSIMM is an observational maturity model that catalogues 121 software security activities observed across participating organisations. ISO/IEC 27034 is an operating framework that names the structure the activities sit inside. BSIMM tells you what other organisations do; ISO/IEC 27034 tells you how to organise your own programme. The activities BSIMM observes typically live as ASCs in the ISO/IEC 27034 library.

ISO/IEC 27034 vs NIST SSDF (SP 800-218)

NIST SSDF is a US federal secure software development framework with four practice groups (Prepare, Protect, Produce, Respond). ISO/IEC 27034 is an international application security governance framework. Programmes serving the US federal market or supplying the federal supply chain operate SSDF as the published practice set, and ISO/IEC 27034 as the underlying organisational structure that produces the SSDF evidence. The cross-reference is straightforward when the ASC library is structured.

ISO/IEC 27034 vs ISO/IEC 27001

ISO/IEC 27001 is the broad information security management system standard with Annex A controls. ISO/IEC 27034 is the application-security-specific operating framework that goes deep where 27001 stays general. Programmes certified to 27001 typically adopt 27034 as the application-security implementation pattern under 27001 Annex A.8.25 (secure development lifecycle), A.8.26 (application security requirements), A.8.27 (secure system architecture and engineering principles), and A.8.28 (secure coding).

ISO/IEC 27034 vs OWASP DSOMM

OWASP DSOMM is a DevSecOps maturity model focused on the build pipeline maturity. ISO/IEC 27034 is the surrounding application security governance framework. DSOMM is most useful for the construction and integration-and-testing lifecycle stages; ISO/IEC 27034 organises every stage from preparation through decommissioning. A mature DSOMM programme produces evidence ISO/IEC 27034 inherits at the relevant lifecycle stages.

Who reads against ISO/IEC 27034

ISO/IEC 27034 has more than one audience inside an organisation, and each one reads the framework from a different angle. The audience lens below is the one we see most often when ISO/IEC 27034 is the application security operating model.

AppSec teams and application security program leads

Hold the ONF, the ASC library, and the per-application ANF derivation. The AppSec read on ISO/IEC 27034 is the catalogue of approved Application Security Controls, the per-application ANF refresh cadence, the verification plan execution, and the per-application Targeted Level of Trust justification. The standard turns ad hoc AppSec advice into a structured catalogue the application teams can read against.

Product security teams

Run the application security lifecycle inside the product organisation. The product security read on ISO/IEC 27034 is the per-product ANF, the construction-stage and integration-and-testing-stage verification evidence, the exception register against the ASC catalogue, and the operations-stage continuous monitoring record per product. The standard formalises the security operating model PSIRT and product security functions already run informally.

Internal security teams and security engineering teams

Run the ASC library, the verification tooling, and the integration with the build pipeline. The security engineering read on ISO/IEC 27034 is the structured ASC catalogue, the SAST/SCA/DAST tooling that produces the verification evidence, the continuous monitoring infrastructure for the operations stage, and the automation that keeps the per-application ANFs in sync with the upstream library revisions.

GRC and compliance teams

Hold the cross-framework evidence pack ISO/IEC 27034 anchors. The GRC read is the ASC-to-framework cross-reference (ISO 27001 Annex A application security clauses, SOC 2 CC7, PCI DSS 6, NIST SSDF, GDPR Article 32), the per-application ANF as the unit of evidence, and the audit trail integrity per verification record. The standard makes the application security evidence pack auditable rather than narrative.

Vulnerability management teams

Operate the per-finding remediation queue against the ASC catalogue rather than against a generic CVE list. The VM read on ISO/IEC 27034 is the per-ASC finding distribution, the lifecycle-stage breakdown of open findings, the exception register per ASC, and the cross-application aging analysis the ASC library supports through structured tagging.

CISOs and security leaders

Hold the application security strategy, the ONF governance, the ASC library evolution, and the leadership reporting against the ANF coverage across the application portfolio. The CISO read on ISO/IEC 27034 is the percentage of applications with current ANFs, the Targeted Level of Trust distribution across the portfolio, the verification cadence adherence, the exception register volume, and the application security maturity progression over time.

Security architects

Own the threat modelling, the design-stage ASC mapping, and the trust boundary catalogue. The architecture read on ISO/IEC 27034 is the per-application threat model anchored to the requirements, the ASC-to-design traceability, the trust algorithm input catalogue per application, and the cross-application architecture patterns the ONF promotes into reusable building blocks.

Where SecPortal fits in an ISO/IEC 27034 programme

SecPortal is the operating record layer for the ISO/IEC 27034 lifecycle, not a replacement for ISO, the build pipeline, the application development platforms, or the runtime defence controls a programme needs. The platform handles the framework-side workstreams (per- application engagement structure, finding intake from SAST, SCA, and DAST against the ANF, verification evidence assembly, exception register, leadership reporting, framework crosswalks) so the inputs the verification reads against are produced as structured records rather than reconstructed at the release gate or at the audit walkthrough.

  • Engagement management dedicated to each application as a long-running record carrying the application-specific ANF, the Targeted Level of Trust, the ASC selection, the lifecycle plan, and the verification plan as one record rather than as parallel folders per audit cycle
  • Findings management with CVSS 3.1 scoring, CWE tagging, structured asset binding, named owner, severity band, and verification evidence, so each finding is recorded against the ASC it fails rather than as a generic bug, with the lifecycle stage at which it was found preserved on the record
  • Code scanning through Semgrep (SAST and SCA) against connected repositories with the rule-pack version stamped on each scan, so construction-stage verification evidence is reconstructable per release and the dependency surface is monitored continuously through operations
  • Authenticated DAST against staging and production with encrypted credential storage (AES-256-GCM with manage_credentials RBAC permission), so integration-and-testing and operations-stage verification of authentication, session, and access-control ASCs produces evidence under realistic auth conditions
  • External scanning across the verified domain surface so the operations-stage continuous monitoring evidence covers the internet-exposed attack surface of the application without manual coordination per cycle
  • Continuous monitoring schedules (daily, weekly, biweekly, monthly) with scan-comparison-and-diff so the new/fixed/unchanged/module-only deltas per scan are recorded as evidence for the operations stage ASC verification
  • Compliance tracking mapping each ASC to its supporting framework citations (OWASP ASVS, ISO 27001 Annex A.8.25 to A.8.28, SOC 2 CC7.1, PCI DSS 6.3.1 and 6.4.1, NIST SSDF, GDPR Article 32, CSA CCM, NIST CSF 2.0 PR.PS, DORA Article 8 to 9) so the ANF verification evidence reads across the framework footprint from one record
  • Finding overrides with structured decision chain (named approver, rationale, effective period, expiry) for the per-ASC exception register the ANF requires
  • Retesting workflows so the closed-loop verification per remediated finding feeds the verification evidence base per ASC; the original evidence and the retest evidence stay paired on the finding record
  • AI report generation that turns the engagement evidence and the verification record into an ANF refresh report, a release-readiness summary, a SOC 2 or ISO 27001 surveillance audit pack, and a board-ready application security report without manual rewriting per audience
  • Document management for the ANF document itself, the threat model, the architecture record, the verification plan, the exception register, the decommissioning record, the per-release verification report, and any third-party assessment evidence
  • Activity log with CSV export capturing every state change to a finding, an ASC verification record, an exception, a credential, or a scan record with timestamp and named user, supporting the audit-trail integrity per ASC verification record
  • Team management with role-based access control (owner, admin, member, viewer, billing) and multi-factor authentication enforcement at the workspace, so the role and responsibility surface ISO/IEC 27034 expects is enforced at the platform that holds the ANF and the verification evidence

Honest scope: what SecPortal is and is not

ISO/IEC 27034 expects the underlying build, runtime, identity, and infrastructure control planes to do the security enforcement work. SecPortal sits next to those control planes as the operating record. The scope statements below clarify the line.

  • SecPortal is not an ISO/IEC 27034 certification body and does not issue formal conformity statements. The standard is an operating framework; certification, where it applies, sits with accredited bodies. SecPortal carries the operating evidence the conformity assessment reads against.
  • SecPortal does not auto-derive the ANF from the ONF. The derivation is a programme decision that requires application context, regulatory exposure, technology stack, and Targeted Level of Trust input; the platform holds the resulting ANF structure as the operating record. The decisions belong to the security and application teams.
  • SecPortal does not publish a prepopulated ASC library covering every ISO/IEC 27034 use case. The catalogue belongs to the organisation under the ONF, with each ASC reflecting the organisation context. The platform holds the library structure (engagement records, finding templates with CVSS vectors, compliance-tracking mappings, document management) so the team builds and maintains the library inside one workspace.
  • SecPortal does not ship packaged push connectors into application development platforms, CI/CD orchestrators, ticket systems, SIEM, SOAR, GRC platforms, asset inventories, CMDB systems, or chat platforms. The integration with adjacent build, ticketing, and security tooling is the customer-side responsibility; the platform exposes the structured ASC and finding records the integration would consume.
  • SecPortal is not a software composition analysis vendor in the dependency intelligence sense, a runtime application self-protection product, or a web application firewall. Code scanning runs through Semgrep against connected repositories for SAST and SCA evidence; runtime defence sits with adjacent tooling the ANF references as a separate control surface.
  • SecPortal does not maintain a real-time SBOM registry, a reachability analysis engine, or a CVE intelligence feed beyond what the connected scanners surface. The dependency catalogue the standard expects sits with the build and supply-chain tooling the operations-stage evidence is sourced from.
  • SecPortal does not automate the Targeted Level of Trust selection or the application security risk assessment that produces it. The trust target is a programme decision; the platform holds the resulting record on the application engagement as part of the ANF.

The application security inputs the ANF verification process depends on are produced through the day-to-day work the same workspace already runs. The security onboarding for new applications workflow carries the preparation-stage and requirements-stage activity each new ANF derivation depends on. The SDLC vulnerability handoff workflow carries the construction-stage and integration-and-testing-stage findings the per-ASC verification reads against. The control-mapping cross-framework crosswalk workflow carries the same ASC evidence across ISO/IEC 27034, ISO 27001 Annex A application security clauses, SOC 2 CC7, PCI DSS 6, NIST SSDF, and the broader audit footprint. The vulnerability acceptance and exception management workflow carries the per-ASC exception register the ANF expects. The audit fieldwork evidence request fulfillment workflow carries the evidence-pack assembly cadence the verification cycle and the audit cycle both read against.

For internal security teams running the programme, the internal security teams workspace bundles the platform with the engagement structure the per-application ANF cadence reads against. For the AppSec function carrying the ASC library and the ANF derivation, the AppSec teams workspace covers the application security operating model. For the product security function carrying the per-product ANF and the construction-stage and integration-stage verification, the product security teams workspace covers the in-product angle. For the security engineering function owning the ASC tooling and the build-pipeline integration, the security engineering teams workspace covers the build-side mechanics. For the GRC function holding the cross-framework ASC evidence pack, the GRC and compliance teams workspace covers the audit footprint. For vulnerability management owning the per-finding queue against the ASC catalogue, the vulnerability management teams workspace covers the operating cadence. For security leaders carrying the ONF governance and the leadership reporting against application portfolio ANF coverage, the CISOs and security leaders workspace covers the programme-level reporting model.

For deeper reading on the disciplines ISO/IEC 27034 reads against, the OWASP ASVS framework page covers the verification standard the ANF most often references for web-shaped applications. The OWASP SAMM framework page covers the maturity model the ISO/IEC 27034 programme is measured against. The NIST SSDF framework page covers the US federal secure software development framework the standard cross-references for federal market service. The ISO 27001 framework page covers the broader information security management system standard the ISO/IEC 27034 programme often sits inside. The secure code review checklist covers the construction-stage review discipline the ASC library expects. The DevSecOps enterprise guide covers the operating shape the construction and integration-and-testing stages most often run inside.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Part 1: Overview and concepts

Names the overall ISO/IEC 27034 model: the Organization Normative Framework, the Application Normative Framework, the Application Security Lifecycle Reference Model, the Application Security Controls, and the Application Security Verification process. Part 1 is the structural blueprint every other part of the family reads against.

Part 2: Organization Normative Framework (ONF)

Defines the ONF: the organisation-wide reservoir of business context, regulatory context, technological context, processes, roles, responsibilities, and the canonical Application Security Control library. The ONF is what every per-application ANF inherits from, owned at the security programme level.

Part 3: Application security management process

Names the operating process for applying the ONF to an application, deriving the application context, setting the Targeted Level of Trust, selecting the applicable Application Security Controls, and producing the per-application ANF. The process the application security manager runs each time a new application enters the catalogue.

Parts 5 and 5-1: Protocols and ASC data structure

Define the structured data format for Application Security Controls so they can be exchanged, catalogued, and version-controlled rather than reinvented in each ANF. Part 5 covers protocols; 5-1 covers the XML schema. The structured ASC is what lets the library scale beyond a per-application binder of bespoke controls.

Part 6: Case studies

Worked examples showing the ONF and ANF in practice across different application classes (web, embedded, mobile, regulated environments). Often the first part security teams read when adopting the standard because it bridges the abstract framework into operating evidence.

Part 7: Application security assurance prediction framework

Defines the assurance prediction surface that lets the programme forecast the security posture of a new application against its ANF before development completes. Part 7 covers the predictive read; the verification process produces the operating evidence the prediction is reconciled against.

Application Normative Framework (ANF) per application

Each application has its own ANF derived from the ONF at provisioning. The ANF records the Targeted Level of Trust, the selected ASCs, the application security lifecycle plan, and the verification plan. It is refreshed on every significant context change rather than maintained as a one-time document.

Application Security Lifecycle Reference Model (preparation, requirements, design, construction, integration and testing, transition, operations, decommissioning)

The reference lifecycle the application security work attaches to so the security evidence is recorded at the stage it was produced rather than reconstructed at audit week. The operations stage is the longest and produces the bulk of audit evidence over the application life.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Find vulnerabilities before they ship

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Monitor continuously catch regressions early

Compliance tracking without a full GRC platform

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Encrypted credential storage for authenticated scans

Repository connections for SAST and SCA

Finding template library pre-written vulnerabilities ready to log

Run the ISO/IEC 27034 ANF cycle on one workspace

Hold the Organization Normative Framework, the per-application Application Normative Framework, the Application Security Controls library, the per-finding evidence, the verification plan execution, the exception register, and the leadership reporting as one record. Carry the same evidence pack across ISO/IEC 27034, OWASP ASVS, ISO 27001 Annex A application security clauses, SOC 2 CC7, PCI DSS 6, NIST SSDF, GDPR Article 32, and CSA CCM without rebuilding it per audit. Start free.

Get Started Free

No credit card required. Free plan available forever.