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.