The conformity claim without an ONF
You are the lead auditor for an independent review of a retail bank's application security programme. The CISO has told the board that the bank 'complies with ISO/IEC 27034'. In the opening meeting the audit sponsor asks you to confirm or refute that statement before the board meeting in ten working days. Document review shows the following. There is no Organisation Normative Framework document, but a wiki holds roughly 60 control entries written by four development teams in incompatible formats. An Application Normative Framework for the mobile payments application lists 38 controls, none traceable to the wiki. That ANF was approved by the delivery manager, although policy assigns approval to the application security manager. The application's targeted trust level is recorded as 'high' with no stated rationale. Two controls carry verification evidence dated three years ago. The application security manager resigned six weeks ago and has not been replaced. No application security management process description exists beyond a two-page slide deck.
1. Explain how the ONF, ANF and ASC artefacts relate to one another, and reach an audit conclusion on whether the CISO's statement can be supported. Frame the answer as a conclusion with reasons, not as a tutorial.
Read the worked answer
Relationship of the artefacts. The ONF is the organisation-level normative framework: it holds the organisation's application security standards, the reusable ASC library, defined roles and authorities, the risk and trust-level criteria, and the process definitions. An ANF is derived per application by selecting and tailoring ASCs from the ONF according to that application's targeted trust level and context. An ASC is the measurable control statement carrying attributes for implementation guidance, verification and validation evidence. The chain ONF to ANF to ASC is what makes an implementation auditable: without an ONF there is no baseline against which an ANF's selection can be judged, and without traceability the 38 ANF entries are assertions rather than derived requirements.
Conclusion: the statement cannot be supported. Reasons:
- No ONF means no approved organisational criteria, so the four teams' 60 wiki entries cannot be shown to be complete, consistent or authorised. They cannot function as a de facto ONF because they are unapproved and mutually incompatible.
- The ANF has no lineage to the wiki, so the selection of its 38 controls cannot be shown to be risk-driven or to reflect any organisational baseline.
- Approval by the delivery manager breaches the organisation's own segregation of duties, so governance evidence fails even against internal policy, before any question of 27034 alignment arises.
- Three-year-old verification evidence does not demonstrate current implementation where releases have occurred; the standard distinguishes verification of the control from validation of its fitness in the operational context, and both must be current.
- Absence of an ASMP description means the process is undefined, so repeatability, ownership and improvement cannot be assessed at all.
Report 'the organisation has partially implemented the concepts set out in ISO/IEC 27034; the claim of compliance is not substantiated'. Do not issue certification-style language.
2. 27034-1 is largely conceptual. State the audit criteria you would actually audit against and show how you would phrase two of the findings so they survive challenge.
Read the worked answer
Because 27034-1 sets out concepts and framework structure rather than a certifiable requirement set, the criteria must be declared explicitly in the report. I would audit against: (i) the organisation's application security policy and its ANF/ONF procedures; (ii) the parts of the ISO/IEC 27034 series the organisation has adopted - for example the ONF content and structure expectations of 27034-2, the application security management process of 27034-3, and the verification and validation expectations of 27034-4; and (iii) the board reporting policy requiring accurate compliance statements. Each finding is then written as condition, criteria, evidence, effect, never as a bare 'nonconformity with 27034-1'.
Finding 1 (traceability). Condition: the mobile payments ANF contains 38 ASCs and no mapping to the organisational control entries. Criteria: the organisation's ANF procedure, which requires each ANF ASC to be selected from the approved organisational library, together with the ONF-ANF relationship it has adopted from 27034-2. Evidence: ANF v2.0 document review; wiki export dated the audit date; walkthrough with the acting application security lead. Effect: the ASC selection cannot be shown to be risk-based, and completeness at the declared high trust level is unverifiable.
Finding 2 (authority). Condition: the ANF was approved by the delivery manager. Criteria: application security policy, which reserves ANF approval to the application security manager. Evidence: ANF signature block; policy clause; HR confirmation of role holder. Effect: the ANF lacks valid authorisation, so releases built against it have no accountable security sign-off.
Where a criterion is the organisation's own policy, the finding is unassailable; where it rests on an adopted 27034 part, quote the adoption decision and the specific expectation relied on.
3. What is the audit significance of the missing targeted trust level rationale, and what evidence would you require before treating that gap as closed?
Read the worked answer
The targeted trust level is not a label; in 27034 terms it is the input that determines which ASCs are mandatory, how rigorous verification must be and what validation in the operational context is required. A recorded level of 'high' with no rationale cannot be tested, because there is nothing to test it against. Two failure modes follow, and the auditor must distinguish them. Either the application genuinely warrants a high trust level and the control set is under-specified, which is a security exposure; or the level was set defensively and the control set is over-specified, which is a cost and proportionality issue. In both cases the ANF's selection is unsubstantiated and any statement that the application is 'at high assurance' is unsupported.
Evidence required for closure:
- A documented determination with rationale: data classification (card data), threat profile, exposure, business and regulatory impact, and the criteria from the ONF used to arrive at the level.
- Approval by the accountable role defined in policy, with a date.
- A re-derivation showing that the mandatory ASC set for that trust level is present in the ANF, with traceability, and that any tailoring is justified and approved.
- Evidence that verification and validation rigour match the level, including current verification records and validation in a production-like context.
- Where the level has changed since previous releases, an assessment of which releases were built against the wrong level.
If the rationale, once produced, shows the level should have been lower, the finding becomes one of process rather than exposure; if it should have been higher, re-scoping of testing is required before any conclusion on effectiveness can be reached.