Industries · Common requirements
Common requirements.
The technical and operating requirements that recur across government, healthcare, transport, financial services, energy and education.
The requirements that survive every sector.
Government, healthcare, transport, financial services, energy and education differ in language, regulation and operating rhythm. They share a set of technical and organisational requirements that determine whether a system can be trusted.
These requirements are often listed in a procurement document as a checklist. The checklist is not the outcome. The outcome depends on whether the requirement is designed into the architecture, tested in operation and evidenced when someone asks.
We use the following framework to structure the conversation and to make the evidence requirements explicit before build begins.
Eight areas that need a design decision.
Each area has a technical component and an operating component. A control that exists only in a document is not a control.
Security
Identity, least privilege, encryption, secure development, vulnerability management and incident response. We define the threat model and the evidence before build.
Privacy
Collection, use, disclosure, retention and access. Data minimisation is applied to design, reporting and support access.
Availability
Service levels, resilience, backup, recovery and maintenance. The target is agreed in business terms, then translated into architecture and operations.
Auditability
Structured event history, decision records, change history and report lineage. Audit evidence is generated by normal operation.
Accessibility
Semantic structure, keyboard access, contrast, assistive-technology support and content clarity, tested against the agreed standard.
Data residency
Hosting, backup, support access and cross-border transfer documented against the client’s obligations.
Integration
Explicit contracts, versioning, failure handling, observability and ownership across system boundaries.
Vendor governance
Exit paths, commercial concentration, support arrangements and the ability to change providers without losing the system.
How we show that a requirement is met.
| Requirement | Design evidence | Operating evidence |
|---|---|---|
| Security | Threat model, access model, architecture review | Access reviews, vulnerability remediation, incident log |
| Privacy | Data map, minimisation decisions, retention rules | Access audit, disclosure record, deletion evidence |
| Availability | Resilience design, recovery objectives | Monitoring, test results, incident reviews |
| Auditability | Event model, lineage design | Report trace, decision history, change log |
| Accessibility | Design standard, component review | Test results, user feedback, remediation log |
We agree the evidence format with the client’s risk, compliance or procurement function. The purpose is not to produce a folder of documents; it is to make the control observable in the way the system actually runs.
Compliance can be complete while the system is still unsafe.
A system can pass a checklist and still fail the people who depend on it. The access review may be current while the recovery plan has never been tested. The privacy policy may be published while support staff can see data they do not need.
We look for the difference between documented control and operating control. That is why our engagements include failure-path testing, operational readiness reviews and a handover that covers the normal, degraded and recovery states.
The standard we aim for is simple: the organisation can explain what the system does, show that it is controlled, and recover it when something goes wrong.
Turning a requirement set into a design conversation.
Procurement documents often contain hundreds of requirements, many of which are copied from a previous tender. A useful response separates the obligations that genuinely shape the architecture from the clauses that can be satisfied by a standard operating practice.
We prefer to review the requirement set with the client before responding. That allows us to identify conflicts, clarify ambiguous language and propose evidence that will be meaningful to the evaluator. A response that claims everything is “fully compliant” without explanation is rarely useful to either side.
- Which requirements are mandatory, weighted or informational?
- Which obligations are derived from law, policy or internal risk appetite?
- What evidence will the evaluator accept: design, test, certification or operating record?
- Which requirements depend on a third party or a client-supplied environment?
- What is the consequence of a gap, and who owns the residual risk?
We can provide a requirement-by-requirement response, an architecture position paper or a short discovery to resolve the uncertain items. The goal is a contract that both parties can operate, not a document that survives only until delivery begins.
Common gaps we find in requirement sets.
Requirement sets often describe features and controls but leave out the operating conditions that determine whether those controls can work. The result is a response that appears compliant but cannot be implemented or supported as written.
- No owner for the business rule or the data definition.
- No definition of what evidence will be accepted for a control.
- No failure-path requirement for an integration or a recovery process.
- No statement of who will operate the system after go-live.
- No distinction between mandatory, weighted and informational requirements.
We prefer to resolve those gaps before a contract is signed. A short clarification workshop is cheaper than a delivery dispute, and it produces a requirement set that both parties can actually use.
Have a requirement set that needs a technical answer?
Send us the constraints. We will help translate them into an architecture, a delivery path and an evidence plan.