When data sovereignty and citizen access set the design
Public sector architecture has an unusual property: the people who have to live with the design will very likely not be the people who made it, and often not even the same organisation.
The situation
The service is citizen-facing or holds citizen data, under obligations about where that data may reside, who may reach it, and how available the service must be to people who have no alternative provider.
The characteristic risks are regional and structural: data crossing a border it should not, a single region with no disaster recovery, a public-facing system with no gateway in front of it, and audit gaps that surface at reporting time.
The distinctive constraint is continuity of understanding. Suppliers rotate, teams rotate, and the design has to remain comprehensible to people who were not there — which makes a model with recorded reasoning worth more here than almost anywhere else.
You are here if
- You cannot state with certainty which region every data store sits in.
- A critical citizen-facing service has no tested disaster recovery position.
- The architecture is documented in a supplier’s format you will lose at contract end.
- Reporting obligations are met by assembling evidence by hand each time.
How the work gets done
Set the availability position for people with no alternative
The government pack sets a workload profile and the targets below. The latency allowance is the loosest of any pack and the residency and continuity questions are the sharp ones — which is a fair reflection of where public-sector risk actually sits.
State the target even where it is modest. An unstated availability expectation is one that gets discovered during an outage.
Simulate ▸ Industry PackSimulate ▸ Workload Profile
Make region and exposure explicit in the model
The pack highlights the policies on public database exposure, redundancy for tier-one components and encryption. Those are checked against the model per component.
Residency itself is not evaluated automatically — record the region on each component and treat it as a review item, because a rule that does not exist should not be relied on as though it does.
Simulate ▸ Policy & StandardsSimulate ▸ Rule Evaluation
Test the single-region assumption
Chaos experiments against the model are the cheapest way to find out what a region loss actually does to a citizen-facing service, and the answer is frequently worse than the continuity plan assumes.
Simulate ▸ Chaos EngineeringSimulate ▸ Resilience Score
Leave a record that outlives the contract
Keep the model, the decisions and the approvals in a form the organisation owns rather than in a supplier’s deliverable. Version history is what lets a successor see not just the design but how it got that way.
This is the argument that carries most weight with a public sector sponsor, and it is the one that is usually made last.
Diagram ▸ Version historyDiagram ▸ Approval workflowDiagram ▸ Export Center
What the Government / Public Sector pack sets
Citizen-facing services and back-office systems. Security clearance, sovereign data residency, and accessibility. Applying the pack switches the workload profile and sets these six targets on the model. It does not change the design and it does not enable any industry-specific check — the targets are what the design is then evaluated against.
| Workload profile | API-First Enterprise — Steady API traffic with strict latency SLAs and high auth overhead. |
|---|---|
| Availability target | 99.5% |
| Latency target (p95) | 1000 ms |
| Throughput target | 300 requests/sec |
| Cost target | $25,000 / month |
| Recovery time objective | 30 minutes |
| Recovery point objective | 300 seconds |
The policies this pack highlights
- No Public Database Exposure — Databases must not be directly accessible from the public internet without a proxy or API gateway.
- Multi-AZ Required for Tier-1 — Critical components must have replicas or be configured for multi-AZ deployment.
- Encryption Required — All data-at-rest components must have encryption enabled.
The risks it names for this industry
These are prompts to work through against your own design, not findings. The pack lists them; nothing evaluates them for you.
- Cross-border data transfer violating sovereignty requirements
- Single-region deployment with no DR for critical services
- Public-facing systems with missing WAF or API gateway
- Audit log gaps for compliance reporting
What is still yours to check
The simulation evaluates the architecture itself — single point of failure, deep synchronous dependency chain, shared database across services, connection pool saturation risk, no autoscaling configured and excessive retry configuration — against the targets above, and the policy checks run on every design. The concerns below are specific to government / public sector and nothing in the product evaluates them. The pack names them so they stay on your list; the review is a human one.
- Data residency and sovereign region placement
- Edge protection on citizen-facing entry points — WAF, gateway, rate limits
- Audit log retention for compliance reporting
- Accessibility and assisted-digital fallbacks for citizen journeys
What you end up holding
- A stated availability and recovery position for a service with no alternative provider.
- Region recorded per component, and per-component exposure and encryption findings.
- A chaos result for the loss of a region rather than an assumption about it.
- A design record and approval history the organisation owns outright.
Not this, if
- You need accreditation against a national security framework. This produces architecture evidence, not accreditation.
- You expect residency to be checked automatically. It is not — record it and review it deliberately.
- The estate is entirely third-party SaaS with no design authority. There is very little architecture left for you to shape.