Application security planning
Planning inputs
Application security planning begins with a risk assessment that considers the application's business context, data classification, threat landscape, and regulatory obligations. From that, the team defines application security requirements and determines the Targeted Assurance Level (TAL). Planning is not a one-off document; it establishes how the Application Security Life Cycle (ASLC) will be governed.
Core rules
- Use the Organization Normative Framework (ONF) as the source of candidate Application Security Controls (ASCs).
- Build the Application Normative Framework (ANF) by selecting and tailoring ASCs that satisfy the requirements.
- If the ONF lacks an ASC for a requirement, define a new ASC and submit it for inclusion in the ONF.
- Assign roles: application security owner, manager, implementers, and verifiers.
- Define verification methods and evidence for each ASC before implementation starts.
- Align the plan with project milestones, budgets, training, and third-party dependencies.
Worked example
A healthcare portal will process patient records. The risk assessment finds high privacy impact and regulatory reporting duties. Planning sets a high TAL, selects ASCs for role-based access, audit logging, encryption in transit and at rest, and adds a new ASC for patient consent management because the ONF has none. The plan names an application security owner, schedules threat modeling before design, and sets verification gates at design review and pre-deployment penetration testing.
Traps
Planning only technical controls and ignoring procedural or people controls is a common gap. Skipping the ANF and moving straight to coding undermines traceability. Failing to revisit the plan when scope, data sensitivity, or regulations change also costs marks.