Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 27034-3 — Application Security — Part 3: Application Security Management Process
Step-by-Step Process for Specifying, Implementing, Verifying, and Maintaining Application Security Controls
ISO/IEC 27034-3 defines the application security management process, providing a detailed, step-by-step methodology for managing application security throughout the application lifecycle. While Part 1 establishes the conceptual framework and Part 2 defines the organizational infrastructure, Part 3 delivers the procedural engine that drives application security activities. This standard is the operational core of the 27034 series, specifying exactly how ASCs are defined, selected, implemented, verified, and maintained across the application portfolio.
ISO/IEC 27034-3 is the most operationally focused part of the 27034 series. It provides the detailed process workflows that security teams can implement directly, including templates for ASC specification, verification checklists, and process flow diagrams.
Application Security Management Process Overview
The process defined in ISO/IEC 27034-3 consists of six major activities that span the entire application lifecycle: (1) Specify Application Security Context, (2) Identify and Specify ASC Requirements, (3) Select and Tailor ASCs, (4) Implement ASCs, (5) Verify ASCs, and (6) Maintain ASCs. These activities are not necessarily sequential in a strict waterfall sense; the standard explicitly recognizes that they may be performed iteratively, concurrently, or incrementally depending on the development methodology. For agile projects, for example, ASC specification and implementation occur incrementally across sprints, while for waterfall projects, they may be front-loaded during the design phase.
A distinctive feature of the 27034-3 process is its emphasis on traceability. Each ASC must be traceable from its origin in the security context and risk assessment, through its specification and implementation, to its verification evidence. This traceability chain provides the basis for audit evidence, regulatory compliance demonstrations, and post-incident analysis. The standard recommends using a traceability matrix or an integrated requirements management tool to maintain these links. For engineering teams, this traceability is not merely a documentation burden but a powerful tool for impact analysis when security requirements change.
| Process Activity | Input | Output | Typical Duration | Verification Artifact |
|---|---|---|---|---|
| 1. Specify Context | Application description, business case, regulatory landscape | Application Security Context document | 1-2 weeks | Reviewed context document |
| 2. Identify & Specify ASCs | Security context, O-ASC library, risk assessment results | Draft ASC list with rationale | 1-3 weeks | Approved ASC specification |
| 3. Select & Tailor ASCs | Draft ASC list, O-ASC library | Application-specific A-ASCs | 1-2 weeks | Tailored A-ASC documents |
| 4. Implement ASCs | A-ASCs, development resources | Secure application with controls | Varies by scope | Code review and build artifacts |
| 5. Verify ASCs | Implemented application, test resources | Verification evidence and reports | 2-4 weeks | Signed verification report |
| 6. Maintain ASCs | Change requests, incident reports, audit findings | Updated A-ASCs and verification evidence | Ongoing | Updated ASC documentation |
Detailed Process Activities and Workflows
The first activity — specifying the application security context — is arguably the most important because all subsequent activities depend on its accuracy. The context specification captures the application’s business value, data sensitivity, regulatory obligations, technical architecture, threat environment, and organizational security policies that apply. ISO/IEC 27034-3 provides a structured template for this specification, ensuring that all relevant factors are considered. The context must be reviewed and approved by the Application Security Officer and the project stakeholders before proceeding to ASC identification.
ASC identification and specification involves selecting candidate ASCs from the O-ASC library based on the application security context. If no suitable O-ASC exists, a new one must be created through the organizational ASC management process defined in Part 2. The selected ASCs are then tailored to the specific application, resulting in A-ASCs. Tailoring may involve adjusting parameter values, selecting subsets of controls, adding application-specific details, or modifying verification criteria. The tailoring process must be documented, and any deviations from the O-ASC baseline must be approved by the Application Security Manager.
The traceability requirement in ISO/IEC 27034-3 has practical benefits beyond compliance. When a vulnerability is discovered in production, the traceability chain enables rapid impact analysis: which ASC should have prevented it, whether verification was adequate, which other applications share the same ASC, and what remediation is needed across the portfolio.
A common pitfall in the 27034-3 process is treating ASC verification as a single gate at the end of development. This approach creates bottlenecks and delays. The standard recommends tiered verification: unit-level verification by developers (Level 1), integration-level verification by testers (Level 2), and independent assessment by security specialists (Level 3). Shift verification left where possible.
Continuous Improvement and Measurement
ISO/IEC 27034-3 includes a maintenance activity that ensures ASCs remain effective throughout the application’s operational life. Maintenance triggers include changes to the application (new features, technology upgrades), changes to the operating environment (cloud migration, new regulations), security incidents that reveal ASC weaknesses, and findings from periodic audits. The standard recommends that each application in production has a current A-ASC specification and that the verification evidence is reviewed at least annually or whenever significant changes occur.
The standard also addresses the measurement of process effectiveness. It defines a set of process metrics that organizations should collect to evaluate and improve their application security process. These include ASC coverage (percentage of applications with current A-ASCs), ASC verification pass rate (percentage of ASCs that pass verification on first attempt), time to remediate verification failures, and number of security incidents attributable to ASC gaps. By analyzing these metrics over time, organizations can identify systemic weaknesses in their process and target improvement efforts where they will have the greatest impact.
Do not confuse ASC implementation with ASC verification. An ASC that has been “implemented” in code but not verified provides no assurance. ISO/IEC 27034-3 requires that each ASC have verifiable evidence of correct implementation before the application is released. Treat verification as a mandatory release gate, not an optional activity. Applications without complete ASC verification should require formal risk acceptance from the governance committee before deployment.
Q1: Can the 27034-3 process be used for third-party applications?
A: Yes, with adaptation. For acquired or third-party applications, the process activities focus on verification rather than implementation. The security context is specified, ASCs are identified from the O-ASC library, and the third-party application is verified against those ASCs. Gaps are addressed through contractual requirements, compensating controls, or risk acceptance.
A: Yes, with adaptation. For acquired or third-party applications, the process activities focus on verification rather than implementation. The security context is specified, ASCs are identified from the O-ASC library, and the third-party application is verified against those ASCs. Gaps are addressed through contractual requirements, compensating controls, or risk acceptance.
Q2: How does 27034-3 handle legacy applications?
A: The standard recommends a risk-based approach for legacy applications. Instead of attempting full ASC coverage, prioritize applications based on their security context (business impact, data sensitivity, threat exposure). For high-priority legacy applications, conduct a gap analysis between existing security controls and the applicable ASCs, then implement compensating controls or accept the identified risks.
A: The standard recommends a risk-based approach for legacy applications. Instead of attempting full ASC coverage, prioritize applications based on their security context (business impact, data sensitivity, threat exposure). For high-priority legacy applications, conduct a gap analysis between existing security controls and the applicable ASCs, then implement compensating controls or accept the identified risks.
Q3: What is the relationship between ASC verification and penetration testing?
A: They are complementary. ASC verification confirms that specific controls are implemented correctly (e.g., “input validation is performed on all user-supplied data”). Penetration testing attempts to bypass those controls (e.g., “try to inject SQL commands through user input fields”). Both are needed for comprehensive application security assurance.
A: They are complementary. ASC verification confirms that specific controls are implemented correctly (e.g., “input validation is performed on all user-supplied data”). Penetration testing attempts to bypass those controls (e.g., “try to inject SQL commands through user input fields”). Both are needed for comprehensive application security assurance.
