ISO/IEC 27034 Lead Application Security Auditor cheat sheet

ISO/IEC 27034 is a multi-part standard: Part 1 overview and concepts, Part 2 activity and process assessment, Part 3 application security management process, Part 4 validation and verification, Part 5 protocols and application security controls data structure, Part 6 security guidance for specific applications, Part 7 (TR) use cases.

Core 27034 vocabulary: Application Security Control (ASC) is a control that addresses application security risk; ASC Library is the repository of all ASCs; Organizational Normative Framework (ONF) is the set of all processes, ASCs, and management activities an organization applies to applications.

Application Security Management Process (ASMP) is a repeatable process that establishes, operates, monitors, and improves application security; it is defined in Part 3 and produces the ONF, the ASC Library, and per-application targets.

The ONF is built from the baseline standard plus organizational context (legal, regulatory, business, technical); each application then selects a subset of ONF ASCs to form its Application Security Control Set.

Risk-based selection rule: an ASC is included in an application's control set when the application's risk profile (data classification, exposure, criticality) meets or exceeds the ASC's applicability criteria.

ISO/IEC 27034 is a guidance/process standard, not a certifiable requirements standard in the way ISO/IEC 27001 is; audits against 27034 assess process conformance and evidence of application of the ONF, not certification of the standard itself.

Application security concepts relevant to 27034 audits: threat modeling, secure development lifecycle (SDL), security requirements, secure coding, security testing (SAST, DAST, IAST, SCA), vulnerability management, and secure deployment.

Key distinction: 27034 addresses application-level security management; ISO/IEC 27001 addresses organizational ISMS; 27034 can be used as a supporting framework within an ISMS, and its ASCs can map to ISO/IEC 27002 controls.

Audit planning must define scope: which applications, which ONF/ASC components, which lifecycle phases (requirements, design, build, test, deploy, operate), and which organizational units and suppliers.

Objectives should be traceable to 27034 elements: ONF establishment, ASC Library completeness, application risk assessment, ASC selection for each application, evidence of ASC implementation, and monitoring/improvement.

Audit criteria must be explicit and documented: the organization's ONF, the ASC Library, the application's control set, and any contractual or regulatory requirements layered on top.

Audit plan contents: objectives, scope, criteria, schedule, audit team roles and competence, sampling approach, evidence requirements, communication plan, and reporting format.

Risk-based sampling: prioritize applications by data sensitivity, exposure to untrusted networks, change frequency, third-party components, and prior findings; document the sampling rationale.

Resource and competence planning: ensure the team includes application security technical competence (code review, testing tools, architecture) plus 27034 process knowledge and audit method competence (ISO 19011).

Evidence plan should specify artifacts to request in advance: ONF documentation, ASC Library records, threat models, risk assessments, SDLC process records, test reports, defect and vulnerability records, change records, and training records.

Pre-audit communication should confirm logistics, evidence requests, interviewee availability, and confidentiality/NDA arrangements; avoid disclosing specific test cases that could compromise sampling integrity.

Opening meeting: confirm scope, criteria, schedule, roles, escalation path, and confidentiality; record attendance and any scope changes agreed.

Evidence collection methods: document review, interviews, observation, and technical verification (code review sampling, configuration review, tool output review, controlled testing where authorized).

Evidence sufficiency rule: evidence must be relevant, reliable, and sufficient; triangulate documentary evidence against interviews and observed practice before concluding.

Sampling in technical review: select code and configuration samples across application tiers, critical functions, and recent changes; record sample size and selection method so conclusions are defensible.

Traceability: each finding must link to a specific audit criterion (ONF element, ASC, or requirement) and to the evidence that supports it; maintain an evidence register.

Interview technique: ask for process descriptions first, then request artifacts that would exist if the process were followed; compare stated process with observed practice.

Technical verification cautions: testing must be authorized, time-boxed, and non-disruptive; production testing requires explicit approval and rollback/stop conditions.

Working papers should record date, auditor, location/system, evidence identifier, observation, criterion reference, and preliminary conclusion; they support the report and any later dispute.

Finding classification rule: nonconformity = failure to meet an audit criterion; observation/opportunity for improvement = weakness without a demonstrated criterion failure; classify consistently and document the basis.

A finding statement should contain: criterion (what was required), evidence (what was found), and significance (why it matters, risk implication); avoid embedding the solution in the finding.

Grading severity by risk: consider likelihood and impact on application security, data sensitivity, exposure, and whether compensating controls exist; document the grading rationale.

Corrective action process: root cause analysis, correction (containment), corrective action (removes cause), responsible owner, target date, and verification of effectiveness.

Verification of corrective action requires evidence, not just a stated completion; re-check the artifact or re-test the control, and record the verification method and date.

Follow-up rule: findings remain open until verified closed; track status, aging, and overdue actions, and escalate per the agreed escalation path.

Reporting should distinguish fact from opinion, avoid attributing findings to individuals, and state limitations of scope and sampling so readers do not over-interpret conclusions.

Closure criteria should be agreed at the opening or in the report: what evidence will demonstrate effective correction and corrective action, and who has authority to close.

Audit team composition rule: match competence to scope - 27034/ONF process knowledge, application security technical depth, sector/regulatory knowledge, and audit method skills; assign roles (lead auditor, technical auditor, auditor-in-training).

Lead auditor responsibilities: plan and manage the audit, allocate work, resolve conflicts, control the audit trail, represent the team to the auditee, and sign the report.

Independence and objectivity: auditors must not audit their own work or have conflicting responsibilities; declare and manage any potential conflict of interest before the audit.

Competence maintenance: track qualifications, training, technical currency (new attack classes, tooling, standards updates), audit experience hours, and performance feedback.

Auditor evaluation inputs: code of ethics adherence, audit report quality, technical accuracy, communication, teamwork, and auditee/stakeholder feedback.

Team briefing before fieldwork: confirm scope, sampling, evidence register format, finding-writing standard, escalation triggers, and daily coordination cadence.

Calibration technique: review draft findings as a team against the criterion-evidence-significance test to reduce inconsistency between auditors.

Ethics and confidentiality: protect sensitive application and vulnerability data, avoid disclosure that increases risk, and follow the organization's responsible-disclosure rules.