D487 A2 Architecture Phase Study Material
Security controls, threat modeling, DFDs, risk mitigation, and OA-style practice
1. What A2 Means
A2 is the Architecture phase of the Security Development Lifecycle. In A2, the team looks at the design
before the software is fully built. The goal is to find design-level risk early and choose security controls
before the code becomes expensive to change.
Plain meaning: A2 asks, “Does the design protect the software before we build it?”
A1 defines the product risk, privacy needs, and security objectives.
A2 turns those inputs into architecture analysis, threat modeling, and risk mitigation.
A3 uses the A2 outputs to create secure design work and security test plans.
A2 in one sentence
A2 is where the team maps the system, finds threats, checks policy compliance, and chooses controls to
reduce risk before implementation moves too far.
2. A2 Exam Clues
The OA often gives a scenario and expects you to identify the phase or the deliverable. If the question
mentions architecture, DFDs, trust boundaries, STRIDE, design risk, or risk mitigation, think A2.
Exam wording Likely answer
Architecture review, system design, design-level A2 Architecture
risk
Data flow diagram, DFD, trust boundary, data store, Threat modeling artifacts
process
STRIDE, spoofing, tampering, repudiation, Threat modeling
information disclosure, DoS, elevation of privilege
DREAD, likelihood, impact, damage, reproducibility, Risk ranking or prioritization
exploitability
Policy compliance analysis during design A2 Policy Compliance Analysis
How to handle each threat: accept, avoid, transfer, Risk Mitigation Plan
mitigate
Open-source component review before usage Open-source selection or compliance review
PII handling, where sensitive data is stored or Privacy information gathering
transmitted
3. Main Goal of A2
The main goal of A2 is to make security part of the architecture. The team should not wait until testing to
discover that the design is unsafe. A2 helps prevent late, expensive fixes.
Find design flaws early.
, Understand data flow and trust boundaries.
Identify threats using a method such as STRIDE.
Rank and prioritize risk using DREAD or similar analysis.
Choose controls that match the threat.
Document mitigation plans before development continues.
4. Inputs to A2
A2 does not start from nothing. It uses the work from A1.
A1 input How A2 uses it
Product Risk Profile Helps decide how deep architecture analysis must
go.
Threat Profile Guides threat modeling focus.
Applicable Laws and Regulations Used during policy compliance analysis.
Third-Party Software List Used to review open-source and dependency risk.
Privacy Impact Assessment planning Helps identify sensitive data flows and access
needs.
Security Objectives Used to select architecture controls.
5. A2 Key Deliverables
Deliverable Plain meaning Exam clue
Business Requirements Security controls must support Business risk, CIA, stakeholder
business needs and CIA goals. needs
Threat Modeling Artifacts DFDs, STRIDE threats, trust DFD, STRIDE, architecture
boundaries, and data diagram
classifications.
Architecture Threat Analysis Detailed review of architecture Prioritize design-level threats
risks and threat priority.
Risk Mitigation Plan Plan for how each risk will be How will threats be handled?
accepted, avoided, transferred, or
mitigated.
Policy Compliance Analysis Checks whether the architecture Adheres to organization security
follows internal and external rules
rules.
Privacy Information Report Documents how PII and sensitive PII storage, access, transmission
data will be handled in the
design.
6. Policy Compliance Analysis in A2
Policy compliance analysis checks whether the architecture follows required rules before the team builds too
much. This can include company policy, industry rules, laws, standards, and security baselines.
Why it matters
It prevents expensive redesign later.
It makes sure the architecture supports security requirements.
It checks whether design choices match legal, regulatory, and company rules.
Security controls, threat modeling, DFDs, risk mitigation, and OA-style practice
1. What A2 Means
A2 is the Architecture phase of the Security Development Lifecycle. In A2, the team looks at the design
before the software is fully built. The goal is to find design-level risk early and choose security controls
before the code becomes expensive to change.
Plain meaning: A2 asks, “Does the design protect the software before we build it?”
A1 defines the product risk, privacy needs, and security objectives.
A2 turns those inputs into architecture analysis, threat modeling, and risk mitigation.
A3 uses the A2 outputs to create secure design work and security test plans.
A2 in one sentence
A2 is where the team maps the system, finds threats, checks policy compliance, and chooses controls to
reduce risk before implementation moves too far.
2. A2 Exam Clues
The OA often gives a scenario and expects you to identify the phase or the deliverable. If the question
mentions architecture, DFDs, trust boundaries, STRIDE, design risk, or risk mitigation, think A2.
Exam wording Likely answer
Architecture review, system design, design-level A2 Architecture
risk
Data flow diagram, DFD, trust boundary, data store, Threat modeling artifacts
process
STRIDE, spoofing, tampering, repudiation, Threat modeling
information disclosure, DoS, elevation of privilege
DREAD, likelihood, impact, damage, reproducibility, Risk ranking or prioritization
exploitability
Policy compliance analysis during design A2 Policy Compliance Analysis
How to handle each threat: accept, avoid, transfer, Risk Mitigation Plan
mitigate
Open-source component review before usage Open-source selection or compliance review
PII handling, where sensitive data is stored or Privacy information gathering
transmitted
3. Main Goal of A2
The main goal of A2 is to make security part of the architecture. The team should not wait until testing to
discover that the design is unsafe. A2 helps prevent late, expensive fixes.
Find design flaws early.
, Understand data flow and trust boundaries.
Identify threats using a method such as STRIDE.
Rank and prioritize risk using DREAD or similar analysis.
Choose controls that match the threat.
Document mitigation plans before development continues.
4. Inputs to A2
A2 does not start from nothing. It uses the work from A1.
A1 input How A2 uses it
Product Risk Profile Helps decide how deep architecture analysis must
go.
Threat Profile Guides threat modeling focus.
Applicable Laws and Regulations Used during policy compliance analysis.
Third-Party Software List Used to review open-source and dependency risk.
Privacy Impact Assessment planning Helps identify sensitive data flows and access
needs.
Security Objectives Used to select architecture controls.
5. A2 Key Deliverables
Deliverable Plain meaning Exam clue
Business Requirements Security controls must support Business risk, CIA, stakeholder
business needs and CIA goals. needs
Threat Modeling Artifacts DFDs, STRIDE threats, trust DFD, STRIDE, architecture
boundaries, and data diagram
classifications.
Architecture Threat Analysis Detailed review of architecture Prioritize design-level threats
risks and threat priority.
Risk Mitigation Plan Plan for how each risk will be How will threats be handled?
accepted, avoided, transferred, or
mitigated.
Policy Compliance Analysis Checks whether the architecture Adheres to organization security
follows internal and external rules
rules.
Privacy Information Report Documents how PII and sensitive PII storage, access, transmission
data will be handled in the
design.
6. Policy Compliance Analysis in A2
Policy compliance analysis checks whether the architecture follows required rules before the team builds too
much. This can include company policy, industry rules, laws, standards, and security baselines.
Why it matters
It prevents expensive redesign later.
It makes sure the architecture supports security requirements.
It checks whether design choices match legal, regulatory, and company rules.
