HMCTS architecture principles
A guide to best practice when designing systems and services for HMCTS and the wider justice sector.
All architects, and anyone involved in designing or building a product or service for HMCTS, should follow these principles.
Justice user needs come first
Design around the people who rely on the justice system — the public, legal professionals, and HMCTS staff — not around existing organisational structures or legacy systems.
API-first
Build services with a documented API from the outset, so capabilities can be reused across HMCTS and the wider justice sector rather than duplicated.
Secure and proportionate by design
Apply the minimum data classification and access controls necessary, in line with the data governance standards, rather than defaulting to the most restrictive option for every case.
Data minimisation
Expose only the data fields a consumer needs for their use case. Avoid returning entire records where a summary will do.
Reuse before you build
Check the API catalogue and existing reference data services before building new integrations or duplicating data that HMCTS already holds elsewhere.
Interoperable by default
Use open standards — REST, OpenAPI, OAuth 2.0 — so systems inside and outside HMCTS can integrate predictably, rather than proprietary formats.
Accessible to all
Digital services must meet WCAG accessibility standards, recognising that court and tribunal users include people with a wide range of needs and circumstances.
Built for change
Design services so they can evolve — new case types, new courts, changing legislation — without requiring a full rebuild each time.