Secure Software Architecture 2026/27 fall

Week 2: risk register and iteration plan

Goal: turn uncertainty into concrete technical risks and decide what to de-risk first.

In the practical session

• create an initial risk register with 8-12 technical risks in /risk/risk_register.adoc;
• include identity/auth risks, integration risks, availability/scalability risks, auditability/privacy risks, and interface evolution risks;
• prioritize risks by likelihood and impact;
• define one possible mitigation, validation step, or design activity for each important risk;
• sketch a coarse iteration plan and state which risks each phase addresses;
• write a first ownership sketch for major future containers/services.

Deliverables due before Week 3

• /risk/risk_register.adoc with prioritized risks;
• /docs/iteration_plan.adoc with phases/iterations and the risks addressed by each;
• /docs/ownership_sketch.adoc with initial ownership assumptions.

Minimum expected content in risk_register.adoc

• 8-12 risks;
• each risk has an ID, statement, likelihood, impact, and treatment;
• each important risk uses the form: "If [condition/event], then [impact]";
• at least one risk related to identity/authentication;
• at least one risk related to authorization/delegation;
• at least one risk related to integration with external organizations;
• at least one risk related to auditability or privacy;
• at least one risk related to availability, scaling, or failure handling;
• at least one risk related to interface evolution.

Minimum expected content in iteration_plan.adoc

• 3-5 project phases or iterations;
• the main artifact produced in each phase;
• the risks each phase reduces;
• what evidence would show that the risk has been reduced.

Questions to answer

• What could make the architecture unsuitable even if all visible features are present?
• Which risks should be addressed before the team commits to a structure?
• What evidence would make a risk less worrying?
• Which containers or services would need clear ownership in a real implementation?
• Which risks are caused by organizational or external-system dependencies?

Quality bar

• risks should be technical enough that architecture work can reduce them;
• "we do not know technology X" is weaker than "if technology X cannot provide property Y, then system goal Z fails";
• treatments should name an architecture/design activity, not only "research more".

Navigation

• Project index
• Previous: Week 1
• Next: Week 3