ISO/IEC 27034 Lead Application Security Auditor study materials
ISO/IEC 27034 Lead Application Security Auditor study resources

ISO/IEC 27034 Lead Application Security Auditor flashcards

ISO/IEC 27034 Lead Application Security Auditor · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Application Security Control (ASC)
A control defined in ISO/IEC 27034 that addresses an identified application security risk. ASCs are stored in a library, selected per application based on risk, and verified during audits.
ASC Library
The repository of all Application Security Controls available to an organization, including their definitions, applicability criteria, and implementation guidance. Auditors check its completeness and maintenance.
Organizational Normative Framework
The ONF is the organization-wide set of application security processes, ASCs, and management activities derived from ISO/IEC 27034 plus organizational context. It is the baseline from which application control sets are selected.
Application Security Management Process
The repeatable process defined in ISO/IEC 27034 Part 3 that establishes, operates, monitors, and improves application security, producing the ONF, the ASC Library, and per-application security targets.
Application Security Control Set
The subset of ONF controls selected for a specific application, based on that application's risk profile. Auditors verify the selection is justified and the controls are implemented.
ISO/IEC 27034 scope
A multi-part guidance standard for application security management, covering concepts, process assessment, the management process, validation and verification, control data structures, and sector-specific guidance.
27034 versus 27001
ISO/IEC 27001 specifies certifiable ISMS requirements; ISO/IEC 27034 provides application-level security management guidance. 27034 can support an ISMS but is not itself a certification standard.
Threat modeling in audits
A structured method identifying threats, attack surfaces, and mitigations for an application. Auditors check that threat models exist, are current, and drive control selection.
Audit scope definition
The explicit boundary of an application security audit: applications, lifecycle phases, organizational units, suppliers, and ONF/ASC components covered. Scope must be documented and agreed before fieldwork.
Audit criteria for 27034
The documented standards against which evidence is judged: the organization's ONF, ASC Library, per-application control sets, and any contractual or regulatory requirements layered on top.
Risk-based application sampling
Selecting applications for audit by data sensitivity, network exposure, change frequency, third-party components, and prior findings. The rationale for selection must be documented in the plan.
Audit plan contents
Objectives, scope, criteria, schedule, team roles and competence, sampling approach, evidence requirements, communication plan, and reporting format. The plan is approved before the audit starts.
Pre-audit evidence request
A list of artifacts requested before fieldwork, such as ONF documentation, threat models, risk assessments, SDLC records, test reports, and training records, to focus on-site effort.
Audit team competence planning
Matching team skills to scope: 27034 process knowledge, application security technical depth (code, testing, architecture), sector/regulatory knowledge, and audit method skills. Gaps must be addressed before fieldwork.
Audit objectives traceability
Each audit objective should map to a specific 27034 element, such as ONF establishment, ASC selection, control implementation, or monitoring and improvement, so conclusions can be tied to criteria.
Opening meeting purpose
Confirming scope, criteria, schedule, roles, escalation path, and confidentiality with the auditee, and recording attendance and any agreed scope changes before evidence collection begins.
Evidence sufficiency
Evidence must be relevant, reliable, and sufficient. Auditors triangulate documents, interviews, and observed practice before concluding that a criterion is or is not met.
Technical verification limits
Code review, configuration review, and testing must be authorized, time-boxed, and non-disruptive. Production testing requires explicit approval plus stop and rollback conditions.
Audit evidence register
A log linking each piece of evidence to its identifier, source, date, auditor, and the criterion it supports, enabling traceability from finding back to evidence.
Interview technique in audits
Ask for process descriptions first, then request artifacts that would exist if the process were followed, and compare stated process with observed practice to detect gaps.
Working paper contents
Date, auditor, system or location, evidence identifier, observation, criterion reference, and preliminary conclusion. Working papers support the report and any later dispute.
Code review sampling
Selecting code and configuration samples across application tiers, critical functions, and recent changes, recording sample size and selection method so conclusions are defensible.
Nonconformity definition
A documented failure to meet an audit criterion, supported by objective evidence. It differs from an observation, which is a weakness without a demonstrated criterion failure.
Finding statement structure
A finding states the criterion (what was required), the evidence (what was found), and the significance (why it matters). The solution is not embedded in the finding statement.
Severity grading rationale
Grading findings by likelihood and impact on application security, considering data sensitivity, exposure, and existing compensating controls. The rationale must be documented, not assumed.
Correction versus corrective action
Correction contains or fixes the immediate problem; corrective action removes the root cause so the problem does not recur. Both need an owner, target date, and verification.
Root cause analysis
Determining why a nonconformity occurred, beyond the immediate symptom, so corrective action addresses the underlying process, competence, or design weakness rather than the instance.
Verification of effectiveness
Confirming corrective action worked by re-checking the artifact or re-testing the control, and recording the method and date. A stated completion without evidence is not verification.
Finding closure criteria
Pre-agreed conditions and evidence that demonstrate effective correction and corrective action, plus the authority responsible for closing the finding. Findings stay open until verified.
Lead auditor responsibilities
Planning and managing the audit, allocating work, resolving conflicts, controlling the audit trail, representing the team to the auditee, and signing the audit report.
Auditor independence
Auditors must not audit their own work or hold conflicting responsibilities. Potential conflicts of interest are declared and managed before the audit begins.
Auditor competence maintenance
Tracking qualifications, training, technical currency on attack classes and tooling, audit experience hours, and performance feedback to keep team competence aligned with scope.