Executive summary
Government systems hold data that residents cannot choose not to give you. That raises the bar, but it does not usually call for exotic controls. The failures we see in the field are ordinary: over-broad access because roles were never modelled, audit trails that record too little to answer a question, non-production environments exposed to the internet, and seeded test accounts that survive into production.
This piece covers the controls that carry most of the weight in a public-sector build, and the handover discipline that determines whether they still hold a year later.
The problem
Public-sector procurement asks about security, usually as a checklist. Checklists are answered at proposal time and rarely revisited during build. Meanwhile the system accumulates the conditions that cause real incidents.
The pattern is consistent. Roles start well-defined and drift, because a user needs one extra screen and the fastest fix is to grant a broader role. Environments proliferate — a UAT copy here, a demo instance there — each with production-like data and none with production-like controls. Documentation is written for the launch and never updated, so the people operating the system a year later do not know what the controls were meant to be.
None of this is a sophisticated attack. It is entropy.
Technical discussion
Model roles against the org chart, then narrow them
Start from the actual offices and the actual functions: who assesses, who approves, who collects payment, who administers. Then apply least privilege by removing everything not required for the function, rather than starting from a permissive role and trimming complaints.
Separate administrative functions from operational ones. The person who processes permits should not be able to change the fee schedule. This separation is also what makes the audit trail meaningful — if everyone is an administrator, the log tells you nothing.
Log what you will actually be asked about
Audit logging is usually either absent or so voluminous it is unusable. The useful question is: what will someone ask us in twelve months? Typically it is who changed this record, who accessed this citizen's data, and who approved this transaction.
Log those against a named account, with a timestamp and the before-and-after where a value changed. Write the log so it cannot be edited through the application. And confirm someone can actually retrieve an answer — an audit trail nobody can query is a storage cost, not a control.
Environment separation is a security control
Non-production environments are where controls are relaxed to make work possible. That is fine until the environment is reachable from the internet, or shares credentials with production, or holds a copy of live citizen data.
Three rules carry most of the benefit: non-production is not anonymously reachable from the public internet; credentials differ from production; and where live data must be used for testing, it is masked. Add noindex headers if a non-production host is reachable at all, but understand that indexing control is not access control.
Handover is part of the security design
The controls that survive are the ones the client can see and operate. That means removing seeded, demo and developer accounts before handover; handing over an account inventory rather than a promise; documenting the role model in language the MIS officer can use; and making sure administrative access does not depend on the contractor still being engaged.
We also recommend agreeing what happens at contract end: who holds the credentials, who can revoke ours, and how the client verifies that revocation happened.
Architecture
A defensible layout for a public-sector application, expressed at the level a TOR can specify:
Recommendations
- Model roles from the offices that exist, then narrow to least privilege.
- Separate administrative from operational functions so the audit trail means something.
- Log the three questions you will be asked — who changed, who accessed, who approved — and test that they can be answered.
- Keep non-production off the public internet, on separate credentials, with masked data.
- Remove seeded, demo and developer accounts before handover, and hand over an account inventory.
- Document the role model for the client's own staff, not for your team.
- Agree the contract-end position: who holds credentials, and how the client verifies revocation.
Conclusion
Very little of this is technically demanding. It is a matter of deciding the access model deliberately, logging with a purpose, keeping environments apart, and treating handover as part of the security design rather than an administrative step after it.