Quick Navigation
- Start here — What architectural risk is
- Regulatory landscape
- Privacy by design
- Security controls as decisions
- Operational risk
- Control points
- Demonstrating compliance
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architecture is one of the primary mechanisms through which organisations manage technical risk and meet regulatory obligations. The structure of a system — its boundaries, integrations, data flows, and access controls — determines its exposure. I've seen teams wait until the security review to think about encryption. By then, it's too late.
Technical risk is architectural risk. Compliance requirements constrain what architectures are permissible. Control points are where risk is managed in the running system — not where it's identified on a whiteboard. Architects must be able to demonstrate how their designs manage risk, not just claim that they do.
Privacy, security, availability, and recovery aren't bolted-on additions — they're architectural decisions.
Keep it in mind.
1. What architectural risk is — How structure creates and reduces exposure
Most people think risk comes from external threats — hackers, outages, regulatory fines. But the biggest source of risk is the architecture itself — the way components connect, the way data flows, the way failures propagate.
Architecture creates risk through coupling, shared resources, and missing controls. Architecture reduces risk through boundaries, redundancy, and designed-in controls.
flowchart TD
ARCH["🏗️ Architecture"] --> CREATES["Creates Risk\nThrough coupling, shared resources\nSingle points of failure\nMissing controls"]
ARCH --> REDUCES["Reduces Risk\nThrough boundaries, redundancy\nDesigned-in controls\nDefence in depth"]
CREATES --> INCIDENT["🚨 Incident\nOutage · Breach\nCompliance failure"]
REDUCES --> RESILIENT["🛡️ Resilient System\nGraceful degradation\nContained failures"]
Examples of architectural risk:
| Architecture decision | Risk it creates |
|---|---|
| Shared database across services | Schema change breaks multiple services |
| No encryption between services | Data intercepted in transit |
| Single region deployment | Region failure causes total outage |
| No rate limiting on API | DDoS brings down the system |
| Hardcoded credentials | Credential leak compromises everything |
Risk categories in architecture: Structural — coupling, dependencies, boundaries. Tightly coupled services — change in one breaks another. Data — ownership, flow, quality, access. Shared database — schema changes cascade. Integration — communication patterns, contracts. Synchronous calls — one slow service blocks all callers. Operational — deployability, observability, recovery. No health checks — failures go undetected. Security — authentication, authorisation, encryption. No encryption at rest — data breach risk. Compliance — regulatory requirements, data sovereignty. Data stored in wrong jurisdiction — GDPR violation.
The risk assessment process: Identify risks — what could go wrong? Assess impact — how bad would it be? Assess likelihood — how likely is it? Score — impact × likelihood. Mitigate through design — architecture decisions that reduce risk. Verify — fitness functions, tests, reviews.
Architecture doesn't just face risk — it creates and reduces risk through its structure.
Try it yourself — The risk audit
What architectural risks exist in your current system?
| Risk | Category | Impact | Likelihood | Mitigation |
|---|---|---|---|---|
If you haven't identified your architectural risks, they're identifying you — in production.
2. Regulatory landscape — The compliance requirements architects must understand
Architects often leave compliance to the legal team. But regulatory requirements directly constrain what architectures are permissible — where data can be stored, how it must be protected, who can access it, and how long it must be retained.
Architects must understand the regulatory landscape well enough to design systems that can comply — not just systems that look good on a diagram.
flowchart TD
REG["📜 Regulations"] --> GDPR["GDPR\nData protection\nEU personal data"]
REG --> PCI["PCI DSS\nPayment card security"]
REG --> HIPAA["HIPAA\nHealth data protection"]
REG --> SOC2["SOC 2\nOperational controls"]
REG --> INDUSTRY["Industry-specific\nFinancial, healthcare, government"]
GDPR --> ARCH["🏗️ Architecture Constraints\nData residency · Encryption\nAccess control · Retention"]
PCI --> ARCH
HIPAA --> ARCH
SOC2 --> ARCH
INDUSTRY --> ARCH
ARCH --> DESIGN["Design Within Constraints\nNot after the fact"]
Key regulations and their architectural implications:
| Regulation | Architectural requirement |
|---|---|
| GDPR | Data residency (EU), right to erasure, consent management, data minimisation |
| PCI DSS | Cardholder data isolation, encryption, access logging, network segmentation |
| HIPAA | PHI encryption, access controls, audit trails, breach notification |
| SOC 2 | Security, availability, processing integrity, confidentiality, privacy controls |
The compliance-to-architecture mapping:
| Regulatory requirement | Architecture decision |
|---|---|
| Data must stay in EU | Cloud region selection — EU-only; no cross-region replication outside EU |
| Data encrypted at rest | All storage services configured with encryption enabled |
| Access logged | Audit logging on all data access — immutable log store |
| Right to erasure | Data tagged with owner; deletion propagates across all stores |
| Minimum privilege | RBAC/ABAC on every service; regular access reviews |
| Breach notification within 72 hours | Automated detection, alerting, and incident response workflow |
The compliance mapping process: Regulatory requirement → Decompose (what exactly does it require?) → Architecture decision (what design satisfies this?) → Verification (how do we prove compliance?) → Evidence (what artefacts demonstrate compliance?).
Regulations are architecture constraints — understand them before designing, not after.
Try it yourself — The compliance check
Which regulations apply to your architecture?
| Regulation | Applies? | Architectural implication |
|---|---|---|
| GDPR | ||
| PCI DSS | ||
| HIPAA | ||
| SOC 2 | ||
| Industry-specific |
If you can't answer the third column, you haven't mapped compliance to architecture.
3. Privacy by design — Building data protection into architecture from the start
Privacy is often treated as a legal requirement handled by the privacy team — bolted on after the system is designed. By then, the architecture makes privacy difficult or impossible to achieve.
Privacy by design means making privacy an architectural property — data minimisation, consent management, purpose limitation, and erasure capability are designed into the system, not added afterwards.
flowchart TD
BOLT["❌ Privacy Bolted On\nAfter design\nPatches and workarounds\nExpensive and fragile"] --> FAIL["Privacy failures\nNon-compliance\nFines and breaches"]
DESIGN["✅ Privacy by Design\nFrom the start\nArchitectural property\nBuilt into data flow"] --> COMPLY["Privacy compliance\nAutomatic erasure\nConsent management\nData minimisation"]
Privacy by design principles: Data minimisation — collect only what's needed. Purpose limitation — use data only for the stated purpose. Consent management — track and enforce user consent. Right to erasure — delete user data on request, everywhere. Data portability — export user data in standard formats. Privacy by default — most private setting is the default.
Privacy architecture patterns: Data minimisation — collect only what's needed. API design — only required fields; no "just in case" collection. Pseudonymisation — replace identifiers with pseudonyms. Tokenisation service; pseudonymised analytics. Purpose-bound storage — data tagged with its purpose. Metadata tagging; purpose-aware access control. Automated erasure — delete all data for a user on request. Erasure orchestration; propagation to all stores. Consent store — centralised consent tracking. Consent service; checked before data processing. Privacy gateway — filter sensitive data before it reaches consumers. Gateway that applies privacy rules at the boundary.
The erasure architecture: User requests erasure → Erasure Orchestrator → Delete from CRM → Delete from Payments → Pseudonymise in Analytics → Retain in logs (legal hold) → Confirm erasure complete.
Privacy = architectural property, not legal afterthought — design it in from the start.
Try it yourself — The privacy check
Can your system handle a right-to-erasure request?
| Question | Your answer |
|---|---|
| Where is user data stored? | |
| Can you delete it from all stores? | |
| Is consent tracked and enforced? | |
| Is data minimised by design? |
If you can't answer the second question, you don't have privacy by design. You have privacy by panic.
4. Security controls as architectural decisions — Not bolted-on additions
Security is often treated as a checklist applied after design — "does it have encryption? does it have auth?" By the time these questions are asked, the architecture has already made implicit security decisions — most of them unconsciously.
Security controls must be architectural decisions — designed into the structure from the start, not retrofitted.
flowchart TD
ARCH["🏗️ Architecture Decision"] --> IMPLICIT["Implicit Security\nDecisions made unconsciously\nShared resources, trust boundaries\nData flows, access patterns"]
ARCH --> EXPLICIT["Explicit Security\nControls designed in\nZero trust, encryption\nAccess control, audit"]
IMPLICIT --> RISK["🚨 Risk\nVulnerabilities by design"]
EXPLICIT --> PROTECT["🛡️ Protection\nDefence in depth"]
Security as architecture — the key decisions:
| Decision | Architecture implication |
|---|---|
| Trust boundaries | Where do you draw the line? What is trusted, what is not? |
| Authentication | Who can call this service? How is identity verified? |
| Authorisation | What can each identity do? RBAC, ABAC, or policy-based? |
| Encryption | What is encrypted, at rest and in transit? Key management? |
| Network segmentation | What can talk to what? VPCs, security groups, service mesh? |
| Audit logging | What is logged, where, and for how long? Immutable storage? |
The security architecture checklist: Network — segmentation, firewalls, WAF. VPC design, security groups, network policies. Application — auth, input validation, rate limiting. API gateway, middleware, framework defaults. Data — encryption, masking, classification. Storage configuration, field-level encryption. Identity — MFA, SSO, service-to-service auth. Identity provider, SPIFFE, mTLS. Monitoring — SIEM, intrusion detection, audit logging. Centralised logging, anomaly detection. Supply chain — dependency scanning, SBOM. CI/CD pipeline, dependency management.
Security control categories: Preventive — stop attacks before they happen. Input validation, encryption, authentication. Detective — detect attacks in progress. Intrusion detection, anomaly monitoring, audit logs. Corrective — respond to and recover from attacks. Incident response, automated remediation, backups. Deterrent — discourage attackers. Rate limiting, account lockout, CAPTCHA.
Every architecture decision is a security decision — make it explicit, not implicit.
Try it yourself — The security check
Where are your implicit security decisions?
| Decision | Implicit or explicit? | If implicit, what's the risk? |
|---|---|---|
If you can't name your trust boundaries, you don't have a security architecture. You have hope.
5. Operational risk — Availability, recovery, and resilience as governance concerns
Systems that are functionally correct but operationally fragile create risk that materialises in production — outages, data loss, slow recovery. These aren't bugs — they're architectural gaps.
Operational risk is managed through architectural decisions about availability, recovery, and resilience — not through operational heroics after something breaks.
flowchart TD
ARCH["🏗️ Architecture"] --> AVAIL["Availability\nHow much uptime?\nRedundancy, failover"]
ARCH --> RECOVERY["Recovery\nHow fast can we restore?\nRPO, RTO, backups"]
ARCH --> RESILIENCE["Resilience\nHow does it degrade?\nCircuit breakers, bulkheads"]
AVAIL --> SLO["📊 SLOs\n99.9% = 8.7 hrs downtime/year\n99.99% = 52 min downtime/year"]
RECOVERY --> RPO_RTO["⏱️ RPO/RTO\nRPO: max data loss\nRTO: max recovery time"]
RESILIENCE --> DEGRADE["🔧 Graceful Degradation\nPartial failure ≠ total failure"]
SLO --> GOVERN["🏛️ Governance\nTargets set and monitored"]
RPO_RTO --> GOVERN
DEGRADE --> GOVERN
Key operational risk decisions:
| Decision | What it governs | Example |
|---|---|---|
| SLO definition | How much availability is acceptable? | 99.95% uptime for payment processing |
| RPO/RTO | How much data loss and downtime is acceptable? | RPO: 5 minutes, RTO: 30 minutes |
| Redundancy | What is single point of failure? | Multi-region for critical services |
| Recovery testing | Can we actually recover? | Quarterly disaster recovery drills |
| Circuit breakers | How do we handle downstream failures? | Automatic fallback when payment gateway is slow |
SLO/SLA/SLI framework: SLI (Service Level Indicator) — the metric being measured. P95 response time, error rate. SLO (Service Level Objective) — the target for the metric. P95 < 200ms, error rate < 0.1%. SLA (Service Level Agreement) — the contract with consequences. 99.9% uptime or financial penalty.
Recovery architecture: Failure → Detect (health checks, monitoring, alerting) → Respond (automated failover, manual intervention) → Recover (restore from backup, switch to standby) → Learn (post-incident review, architecture improvement).
Resilience patterns: Circuit breaker — stops calling a failing service. Downstream service failures. Retry with backoff — retries failed calls with increasing delay. Transient failures. Bulkhead — isolates failure domains. Multi-tenant or multi-service systems. Graceful degradation — returns partial results when full results unavailable. Non-critical features. Rate limiting — prevents overload from excessive requests. Public APIs, shared resources.
Operational risk is architectural — availability, recovery, and resilience are design decisions, not ops tasks.
Try it yourself — The operational check
What are your SLOs and RPO/RTO?
| Service | SLO | RPO | RTO | Tested? |
|---|---|---|---|---|
If you haven't tested recovery, you don't have an RTO. You have a guess.
6. Control points — Identifying where risk is managed in the architecture
Risk isn't managed everywhere — it's managed at specific points in the architecture. Identifying these control points is essential for understanding where the system is protected and where it's exposed.
Control points are the places in the architecture where risk is actively managed — where authentication happens, where data is encrypted, where access is checked, where failures are caught.
flowchart TD
FLOW["📊 Request Flow"] --> CP1["🔑 Control Point 1\nAPI Gateway\nAuthentication + Rate Limiting"]
CP1 --> CP2["🔐 Control Point 2\nService Mesh\nAuthorisation + mTLS"]
CP2 --> CP3["💾 Control Point 3\nData Access Layer\nEncryption + Audit Log"]
CP3 --> CP4["📋 Control Point 4\nAudit Store\nImmutable Log + Alerting"]
The control point register:
| Control point | Location | Risk managed | Control implemented | Owner |
|---|---|---|---|---|
| API Gateway | Entry point | Unauthenticated access | OAuth2 + JWT validation | Platform team |
| Service mesh | Between services | Lateral movement | mTLS + RBAC | Platform team |
| Data access layer | Before database | Unauthorised data access | Row-level security + audit | Domain team |
| Audit store | After action | Non-repudiation | Immutable log + alerting | Security team |
Discovering control points: Data flow analysis — where does data enter, move, and exit? Every boundary is a potential control point. Trust boundary analysis — where does trust level change? Every trust boundary needs a control. Attack surface analysis — where can an attacker interact with the system? Every entry point is a control point. Failure mode analysis — where can failures propagate? Every failure boundary needs a control.
Control point verification: Identify control point → Is the control implemented? No → implement. Yes → is the control effective? No → fix. Yes → is the control monitored? No → add monitoring. Yes → verified. Control point is healthy.
Control points = where risk is managed — identify them, verify them, own them.
Try it yourself — The control point map
Where are your control points?
| Control point | Location | Risk managed | Verified? |
|---|---|---|---|
If you can't name your control points, you don't know where your system is protected.
7. Demonstrating compliance — How architecture is used to evidence regulatory adherence
Compliance isn't just about being compliant — it's about being able to prove it. Auditors, regulators, and customers need evidence that the architecture meets its obligations. If you can't demonstrate compliance, you're not compliant.
Architecture artefacts — ADRs, diagrams, control registers, test results — become the evidence base for compliance demonstration.
flowchart TD
ARCH["🏗️ Architecture Artefacts"] --> ADRS["ADRs\nDecisions and rationale"]
ARCH --> DIAGRAMS["Diagrams\nData flows and boundaries"]
ARCH --> CONTROLS["Control Register\nControls and verification"]
ARCH --> TESTS["Test Results\nFitness functions and audits"]
ADRS --> EVIDENCE["📋 Compliance Evidence"]
DIAGRAMS --> EVIDENCE
CONTROLS --> EVIDENCE
TESTS --> EVIDENCE
EVIDENCE --> AUDIT["🔍 Audit / Review\nDemonstrates adherence"]
What auditors look for:
| Question | Architecture evidence |
|---|---|
| "How is data protected?" | Encryption control points in architecture diagram |
| "Why was this technology chosen?" | ADR with risk assessment |
| "How is access controlled?" | IAM architecture with RBAC/ABAC design |
| "What happens when a breach occurs?" | Incident response architecture and runbooks |
| "How is data retained and deleted?" | Data lifecycle architecture with retention policies |
Evidence mapping:
| Regulatory requirement | Architecture evidence | Format |
|---|---|---|
| Data encrypted at rest | Architecture diagram showing encryption at storage layer | Diagram + config evidence |
| Access control implemented | IAM architecture with RBAC design | ADR + access review records |
| Audit trail maintained | Logging architecture with immutable store | Diagram + log retention policy |
| Data residency enforced | Cloud region selection ADR | ADR + infrastructure config |
| Incident response plan | Incident response architecture | Runbook + drill evidence |
Fitness functions as compliance automation: Automated compliance check: all data stores encrypted. Rule: "All storage resources must have encryption at rest enabled." Enforcement: "Terraform plan scan — block if violated." Evidence: "CI/CD pipeline output as audit artefact."
Architecture artefacts are compliance evidence — design them to be audit-ready, not just design-ready.
Try it yourself — The evidence check
If an auditor asked today, what evidence could you provide?
| Requirement | Evidence available? | Format |
|---|---|---|
| Data encrypted at rest | ||
| Access control implemented | ||
| Audit trail maintained | ||
| Data residency enforced |
If you'd need to fabricate evidence, you're not compliant. You're lucky.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
ARCH["🏗️ Architecture Decisions"] --> RISK["⚠️ Risk\nStructure creates\nand reduces exposure"]
ARCH --> COMPLY["📜 Compliance\nRegulations constrain\nwhat is permissible"]
ARCH --> CONTROL["🎯 Control Points\nWhere risk is managed\nin the running system"]
ARCH --> DEMO["📄 Demonstrate\nArtefacts as evidence\nof adherence"]
RISK --> VALUE["✅ Resilient, Compliant System\nRisks designed against\nCompliance built in\nEvidence ready"]
COMPLY --> VALUE
CONTROL --> VALUE
DEMO --> VALUE
The foundation:
Technical risk is architectural risk — the structure of a system creates and reduces risk. Design against risk, don't just identify it. Compliance is an architecture constraint, not a legal afterthought — understand the regulations before designing, and build compliance into the architecture from the start. Control points are where risk is managed — identify them, verify them, own them. If you don't know where your control points are, you don't know where your system is protected. Risk is managed through design, not firefighting. Compliance is built in, not bolted on. Evidence is produced by architecture, not fabricated for audits.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Architectural risk | Structure creates and reduces exposure | Analyse risk in every design decision |
| Regulatory landscape | Regulations constrain architecture | Map requirements to design decisions |
| Privacy by design | Privacy as architectural property | Data minimisation, consent, erasure |
| Security controls | Every decision is a security decision | Design in, don't bolt on |
| Operational risk | Availability, recovery, resilience are design decisions | Define SLOs, RPO/RTO, resilience patterns |
| Control points | Where risk is managed | Identify, verify, own |
| Compliance demonstration | Artefacts as evidence | Design audit-ready documentation |
How to know if this landed
You'll know this has landed when someone stops treating security and compliance as afterthoughts and starts treating them as architectural properties. Can identify the top 5 architectural risks in their current systems. Understands the key regulations that constrain their architecture (GDPR, PCI, HIPAA, SOC 2). Privacy is designed in — data minimisation, consent management, erasure capability. Security controls are architectural decisions — not afterthoughts. SLOs and RPO/RTO are defined and monitored for critical services. Control points are identified, documented, and verified. And architecture artefacts serve as compliance evidence — ADRs, diagrams, control registers.
What changes when the mental model clicks
I've run this session with a healthcare SaaS platform where HIPAA and GDPR requirements were discovered after the architecture was designed — massive rework. No control points identified — auditors couldn't verify how data was protected. Single region deployment — no disaster recovery plan. Security controls were a checklist applied at the end — encryption gaps discovered in production. The gap at the start is usually not about understanding risk — it's about not designing against it from the start.
What changes after this session:
Teams stop treating compliance as a legal afterthought and start treating it as an architecture constraint. The control point identification exercise — "where is risk managed in our architecture?" — is always the moment things click. People stop bolting on security and start designing it in. Their results get better. They stop discovering encryption gaps in production when the real problem was that they hadn't made security an architectural decision.
The compliance evidence exercise tends to immediately change how teams think about their architecture artefacts. They start designing ADRs and diagrams to be audit-ready. Their compliance readiness goes up. They stop fabricating evidence for audits when the real problem was that they hadn't produced evidence by design.
Book a Workshop
Ready to build risk and compliance into your architecture from the start?
or
1-day workshop includes architectural risk analysis — identify and score risks in your real systems, regulatory mapping — connect GDPR, PCI, HIPAA, SOC 2 to your architecture decisions, privacy by design workshop — design erasure, consent, and minimisation into your data flows, control point identification — map where risk is managed in your architecture, compliance evidence design — make your architecture artefacts audit-ready, and risk and control register template + compliance mapping guide + architecture risk heat map.