CPD timing for this level
Foundations time breakdown
This is the first pass of a defensible timing model for this level, based on what is actually on the page: reading, labs, checkpoints, and reflection.
What changes at this level
Level expectations
I want each level to feel independent, but also clearly deeper than the last. This panel makes the jump explicit so the value is obvious.
Correct diagrams, boundaries, and responsibilities.
Not endorsed by a certification body. This is my marking standard for consistency and CPD evidence.
- One clear system sketch (C4 at a simple level): users, core components, data stores, and external dependencies.
- Two ADRs: one trade-off you chose, and one assumption you wrote down with a plan to verify it.
- A lifecycle evidence pack for one feature: NFRs, threat sketch, tests, rollout plan, and an ops checklist.
Software Architecture Foundations
CPD tracking
Fixed hours for this level: 24. Timed assessment time is included once on pass.
View in My CPDWelcome to the foundations tier of the Software Architecture course. This programme takes you through the software development lifecycle with security integrated as a normal engineering concern, not a late-stage “security review”.
- iSAQB CPSA-F: architecture design methods and communication
- ISO/IEC/IEEE 42010: viewpoints and architecture descriptions
- TOGAF: architecture development approach
- OWASP: secure development and verification thinking
- Microsoft SDL / NIST SSDF: secure software development practices
Course structure
This foundation tier is organised around the software development lifecycle with security integrated throughout.
Quick check: architecture foundations across the lifecycle
What is an architecture decision record used for
What is a non-functional requirement
Scenario: A product says it must be fast. What is the minimum you must add to make that a real requirement
Why is threat modelling useful early
What is the goal of CI/CD in one line
What does DevSecOps mean in practice
Scenario: A security review finds auth issues after launch. What lifecycle artefact would have reduced the risk earlier
What does OWASP ASVS help with
Why does observability matter
What is an incident in SRE terms
Why use the OSI model in troubleshooting
What is an 'ility' example
🧪Worked example. A feature that looks “done” until it meets reality
Example scenario: “Add password reset to the product”.
- Discovery: who uses it, what counts as success, and what harm looks like if it is abused.
- Design: flows, rate limiting, logging, privacy considerations, and failure modes.
- Build: validation, secure tokens, safe messaging, and audit trails.
- Test: abuse cases (enumeration, reset spam), accessibility, and performance under load.
- Deploy: safe rollout, monitoring, and rollback.
- Operate: alerts, runbooks, and incident response if compromise is suspected.
My opinion: most “secure by design” is just “design like someone will actually use and abuse it”. The earlier you write the failure modes down, the cheaper they are to fix.
⚠️Common mistakes (foundations tier)
- Treating architecture as diagrams only, not decisions and trade-offs.
- Writing NFRs as slogans (“fast”, “secure”) without measurable thresholds.
- Threat modelling once, then never revisiting as features evolve.
- Shipping without observability, then debugging by guesswork.
🔎Verification. What “good foundations” looks like in practice
- You can explain the system in one minute to a non-technical stakeholder and still be accurate.
- You can list the top 3 risks and the controls that reduce them.
- You can name the key signals you would monitor after launch.
- You have at least one test or review step that targets abuse paths, not only happy paths.
🧾CPD evidence (practical, defensible)
- What I studied: lifecycle view of architecture, security-by-design basics, verification habits, and operational readiness.
- What I practised: one journey map, one threat model sketch (lightweight), and one monitoring checklist for a key feature.
- What changed in my practice: one habit. Example: “I write the failure cost and rollback plan before I ship.”
- Evidence artefact: a one-page architecture note (context, assumptions, risks, signals).
Module 1: Discovery and Requirements (2.4 hours)
Learn to identify what you're building and what could go wrong. Covers user journeys, non-functional requirements, threat modelling fundamentals with STRIDE, and abuse cases mapped to OWASP Top 10.
Discovery and Requirements
User journeys, NFRs, threat modelling, and abuse cases
How to use: open the tool, follow the inputs, and run with limits shown.
Module 2: Architecture and Design (2.8 hours)
Document and communicate architectural decisions using C4 models, Architecture Decision Records, API contracts, and security by design principles.
Architecture and Design
C4 models, ADRs, API contracts, and security by design
How to use: open the tool, follow the inputs, and run with limits shown.
Module 3: Implementation (Build) (3.0 hours)
Write secure, maintainable code with proper input validation, output encoding, session management, error handling, and supply chain security.
Implementation (Build)
Secure coding, session management, error handling, and supply chain security
How to use: open the tool, follow the inputs, and run with limits shown.
Module 4: Verification and Testing (3.5 hours)
Ensure quality and security through comprehensive testing strategies, OWASP ASVS integration, accessibility testing with WCAG 2.2, and performance testing.
Verification and Testing
Test strategies, OWASP ASVS, accessibility testing, and performance validation
How to use: open the tool, follow the inputs, and run with limits shown.
Module 5: Deployment and CI/CD (2.5 hours)
Automate secure deployments with CI/CD pipelines, DevSecOps integration, deployment strategies, and Infrastructure as Code basics.
Deployment and CI/CD
CI/CD pipelines, DevSecOps, deployment strategies, and IaC basics
How to use: open the tool, follow the inputs, and run with limits shown.
Module 6: Operations (3.2 hours)
Run systems reliably in production with Google SRE principles, four golden signals, observability triad, and effective incident response.
Operations
SRE principles, golden signals, observability, and incident response
How to use: open the tool, follow the inputs, and run with limits shown.
Module 7: OSI Model and Browser/Terminal Diagnostics (1.8 hours)
Master troubleshooting tools and techniques using OSI layers, browser DevTools, command-line diagnostics, and TLS certificate inspection.
OSI Model and Diagnostics
Network fundamentals, browser DevTools, and command-line diagnostics
How to use: open the tool, follow the inputs, and run with limits shown.
Module 8: The 'Ilities' Framework (2.0 hours)
Evaluate systems across quality attributes including security, privacy, accessibility, performance, reliability, scalability, maintainability, and more.
The 'Ilities' Framework
Comprehensive quality attributes for system evaluation
How to use: open the tool, follow the inputs, and run with limits shown.
Assessment and certification
Complete the assessment and a short reflection portfolio to consolidate learning. Certificates (if provided) should be treated as evidence of participation, not as a guarantee of competence.
Next steps
After completing this Foundation tier, progress to the Intermediate tier (30 CPD hours) for advanced topics in security architecture, cloud-native patterns, performance engineering, and more.