Well after the platform had launched, the privacy officer sent the API platform team three questions. Which APIs are live? Who calls them? What personal data do they return? The team expected to answer from a dashboard. It turned into an investigation.
By the usual measures the programme had gone well. It opened an agency’s services to other agencies and approved partners, teams shipped quickly, and partners integrated faster than planned. It also had a standards document, and most teams followed most of it. What it lacked was any way to see the estate it had built, so answering three plain questions meant going back through gateway logs, network scans, and interviews with engineers who had since moved on. We’ve merged several programmes into one here and changed the details that would identify them. Nothing below is invented.
Governance had become a project, with its own budget and deadline. In the programmes that avoid this, it’s something the platform does every day without being asked. It matters in government because every credential an agency issues is a statement about who it trusts with citizens’ data. A credential is a trust decision made in code, which is the argument of Trust Is an Engineering Output, and a programme opening public sector APIs to partners makes hundreds of them.
The first audit
The clearest way to see what went wrong is to follow one API: the eligibility check, the programme’s busiest service. The audit found two versions of it running. The newer one filtered out fields partners didn’t need. The older one didn’t, and one partner was still calling it. Three clients shared a single API key, so the gateway could show that the API was busy but not who was busy. A test copy, loaded with production data so a partner could try things out, was still reachable months later. And the API’s OpenAPI document described the service as it was at launch, which no longer matched what was deployed.
Elsewhere in the estate, two teams had put APIs straight behind a load balancer to meet a deadline, so the gateway didn’t know they existed. The OWASP API Security Top 10 calls this improper inventory management, one of the ten most critical API risks, and its list of warning signs reads like the audit report: hosts with no clear purpose, no record of which version is running or who should reach it, stale documentation, and no retirement plan. Its first example is a beta host running production’s API without production’s protection. OWASP also advises against production data in non-production deployments, and says that where it can’t be avoided, those deployments need the same protection as production (OWASP, 2023).
The test copy was the one finding nobody tried to defend. The privacy impact assessment had been done properly at launch, but it described the design, and by the time of the audit the design and the estate were two different things.
What governance after the fact buys you
Here is how the eligibility API got to that state, one sensible step at a time.
It was built in a sprint to meet a partner’s go-live date, and the OpenAPI document was written afterwards for the developer portal. The design review board saw it early and approved it. Later the partner asked for three more fields, which were added in a minor release that never went back to the board. Someone added a row to the API register spreadsheet at go-live, and nobody updated it again. The partner received an API key by email and, a few weeks on, shared it with two contractors working on a joint service. After a privacy concern, the team shipped a version 2 with proper field filtering. Version 1 stayed up because nobody could say who was still calling it, and turning it off might break a service they didn’t know about.
Each of those steps passed the governance the programme had: the board, the register, the standards document, and the plan for a periodic audit. That model buys real things. It gives security and privacy teams a place to ask questions, and the board brings judgement no tool can supply: whether a new data flow is justified, whether a field is needed, whether an existing API could be reused instead. What it can’t do is keep up. The register drifts from the day it’s finished. A board that meets on a fixed schedule becomes a queue, and teams under deadline find ways around queues. The standards document describes the rules but has no way to stop an API that breaks them, and a periodic audit reports on a single day.
Keep the board, and take routine conformance off its desk, so it only sees the decisions that need people, such as a new category of personal data or a new external consumer.
What governance built in looks like
Now run the same API through a platform that governs as it goes.
The first draft of the eligibility API arrives as an OpenAPI document, before any code. The UK’s API technical and data standards recommend exactly this: make the OpenAPI document the first output of design, lint it for rule and security problems, and generate the reference documentation from it (Government Digital Service and Central Digital and Data Office [GDS and CDDO], 2026). The specification is a standard, language-agnostic description of an HTTP API that both people and tools can read (OpenAPI Initiative, n.d.). The draft includes a date-of-birth field, and the pipeline flags it because the field carries no data classification. OpenAPI has no built-in marker for personal data, so agencies add their own extension or link fields to a data catalogue. The privacy officer sees the question in a pull request before the API exists, instead of in an audit after partners depend on it.
A few months in, the partner asks for three more fields. The pull request fails the linter because none of them is classified, and the privacy officer approves two of the three in the review thread. Nothing reaches production without passing the same checks, and the deployed service is compared against its specification on every release, so the document the portal shows is the one that’s running.
Publishing goes through one door. The gateway is the only way to reach an API from outside its network, and network policy enforces that, so the catalogue of externally reachable APIs stays complete for as long as the policy holds. Regular discovery scans of cloud accounts, DNS, and certificates check that it does, and they’re what would have found the two APIs behind the load balancer. The partner’s sandbox is generated from the specification and seeded with synthetic data. The UK standards say test services should never hold real personal or transactional data and should still require authentication (GDS and CDDO, 2026), so the exposed test copy from the first story never gets built. GSA’s own API standards, which apply to GSA rather than the whole US government, require something similar for its public APIs: listing in its API directory, versioning, an OpenAPI file, and a shared management service that handles keys, rate limits, and usage analytics (General Services Administration, n.d.). That model runs on API keys rather than OAuth, which suits open data better than personal data, but the idea of one managed route with usage analytics carries over.
The contractors arrive next. Each is onboarded as its own consumer under the data-sharing agreement, with a client whose credential is bound to a key or certificate it holds, so a copied secret is useless and any one of them can be cut off without touching the others. The UK standards recommend OAuth 2.0 for API access control, with client credentials when a service calls on its own behalf, token exchange when it calls on behalf of a user, scopes checked on every request, and API keys avoided where possible. They also require agencies to log when personal or sensitive data is provided and to whom (GDS and CDDO, 2026).
Then version 2 ships. Telemetry shows which clients still call version 1, and GSA’s standards describe using that kind of analytics data to notify recent users before a breaking change (General Services Administration, n.d.). The guidance pulls two ways here, because GSA asks teams to keep at least one previous major version running, while OWASP points out that every live version is attack surface and needs a retirement plan (OWASP, 2023). A workable rule is that an old version stays only while it has callers, and only with the same protection as the new one. The last partner still on version 1 moves across a few weeks after being told, and version 1 is switched off.
Sakura designed something close to this with SkillsFuture Singapore in 2020 (how SkillsFuture Singapore gated its API lifecycle). Each API moved through four stages (Inception, Build, Adoption, and Close), and each stage had entry and exit criteria. REST, OpenAPI, and JSON Schema were mandatory, the OWASP REST Security Cheat Sheet was enforced at the endpoint level, and nothing was published until it had passed a conformance test against the framework. The framework treated the teams building APIs and the teams consuming them as separate groups with different cadences and different controls. Standards were set centrally and day-to-day decisions stayed with the teams, which was intended to keep the gates from turning into a queue. It also kept a periodic check in place, a quarterly maturity assessment using Apigee Compass, because a platform that enforces the rules still benefits from someone asking whether they’re the right ones.
The platform architecture that supports it
Underneath that walk-through, API platform architecture comes down to one component per stage of the API lifecycle, each leaving evidence behind as a side effect of doing its job.
| Stage | Component | What it records |
|---|---|---|
| Design | Specification repository and linter | The OpenAPI document, field classifications, and lint results |
| Build | CI pipeline with conformance and security tests | Test results tied to each version |
| Publish | Gateway, developer portal, sandbox, and network policy | A catalogue entry generated from the specification |
| Consume | Identity provider, gateway scope checks, and authorisation in the API | Per-client credentials and a log of personal data provided |
| Change and retire | Traffic telemetry | Callers per version, per client |
| Around all of it | Discovery scans and drift checks | Anything reachable that the platform doesn’t know about |
The gateway’s scope check only decides which operations a partner can call. The API itself still has to decide which records and which fields that partner may see. Together they’re the technical side of a data-sharing agreement, and API security depends on both, though neither covers the agreement’s terms on purpose, retention, and onward sharing.
API observability should also record every call by API, version, client, and response class, along with a pseudonymous reference to the record returned, without logging the payload itself. The privacy officer’s first two questions then become a query, and the log can still show which client received a given person’s record. The third question becomes a query too, once fields are classified in the specification and responses are validated against it.
Most agencies already own some of these parts. The UK standards note that access control, audit and logging, and network management are services an API management platform provides that rarely make sense to build yourself (GDS and CDDO, 2026). NIST’s guidance on API protection sorts its controls into pre-runtime and runtime stages, and its March 2026 update adds an appendix listing recommended controls by API lifecycle stage, a useful cross-check for the table above (Chandramouli and Butcher, 2026). The harder work is the wiring between components, so each one feeds the next. Our Cloud practice builds that wiring on whichever clouds the agency already runs.
What belongs in the tender
Few agencies build every row of that table themselves. The gateway might be a managed service, identity a SaaS tenant, and telemetry a monitoring vendor’s pipeline. The platform trusts all of them, and every one is run by an operator that answers to the law of one or more jurisdictions. The first post in this series followed an agency whose sovereign platform leaked through the services around it, and a directory synchronised to a global tenant was the largest single cause (Sovereign Cloud Is an Architecture, Not a Procurement). An API platform leans on identity even harder. The gateway’s scope checks and the API’s own record and field decisions both trust whatever the authorisation server issues. Anyone who operates that server, holds its signing keys, or can compel either of them can create access that the rest of the table will honour.
Most of the tenders we see still leave that surrounding estate to engineering after signature. Key custody is the exception, and it shows up in requirements more often now, usually as customer-held or externally managed keys. Identity and telemetry are the biggest gaps. It’s rare for a tender to ask who operates the identity provider and under which law, or where logs and traces go once they leave the platform. The answers then arrive one integration at a time, after the price is fixed.
What works is a dependency inventory submitted with the tender. Each bidder lists every external service the platform needs in order to operate, with its operator and jurisdiction. That covers the identity provider and who holds its token-signing keys, where logs and traces are sent, the support access paths for the supplier and any subcontractors, the CI/CD tooling, and any managed gateway or developer portal. The agency adds what it supplies itself, such as an existing directory the platform will federate to, because no bidder’s list will show that. Since the requirement is in the tender documents, every bidder answers the same question, and the inventory can be scored, set as pass or fail, or refined in a negotiation round where the procedure allows one. At award it becomes a contract schedule. Adding a service then needs notice and the agency’s approval, much as GDPR already requires a processor to get written authorisation before engaging a sub-processor (European Parliament and Council, 2016, Article 28(2)). From there, egress monitoring checks the running estate against the schedule, so a new dependency shows up as drift instead of as an audit finding.
The trust the platform produces
Send the privacy officer’s three questions to an agency running a government API platform built this way, and the answers come from data it already holds. Partners can rely on published contracts, managed versions, and notice before a breaking change. Auditors get evidence the platform produced while running, not a reconstruction. Delivery teams building government digital services find the governed path is also the quickest one, so they have fewer reasons to route around it.
Someone has to run the platform, and its gates have to be quick, or they become the review-board queue again in automated form. An agency with hundreds of existing APIs can’t move them all at once. It can require the platform for every new API, then bring the existing estate across in order of risk, starting with APIs that return personal data or serve the most external consumers, and using gateway traffic plus a discovery scan to decide the order. Contracts for APIs that a supplier builds or hosts for the agency can require the same platform route, with the same specification and conformance checks as everything else.
The privacy officer will ask the same three questions again, and next time the answer should take a query, not an investigation. Keeping access control and security testing current as partners and threats change is the part our Security practice does with agency teams.
References
Chandramouli, R. and Butcher, Z., 2026. Guidelines for API Protection for Cloud-Native Systems. NIST Special Publication 800-228, June 2025, includes updates as of 13 March 2026. National Institute of Standards and Technology. Available at: https://csrc.nist.gov/pubs/sp/800/228/upd1/final [Accessed 30 September 2026].
European Parliament and Council, 2016. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). Official Journal of the European Union, L 119, 4 May, pp. 1-88. Available at: https://eur-lex.europa.eu/eli/reg/2016/679/oj [Accessed 30 September 2026].
General Services Administration, n.d. GSA API Standards. US General Services Administration. Available at: https://github.com/GSA/api-standards [Accessed 30 September 2026].
Government Digital Service and Central Digital and Data Office (GDS and CDDO), 2026. API technical and data standards. GOV.UK, last updated 30 September 2026. Available at: https://www.gov.uk/guidance/gds-api-technical-and-data-standards [Accessed 30 September 2026].
OpenAPI Initiative, n.d. OpenAPI Specification v3.2.1. The Linux Foundation. Available at: https://spec.openapis.org/oas/latest.html [Accessed 30 September 2026].
OWASP, 2023. API9:2023 Improper Inventory Management. OWASP API Security Top 10. Available at: https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/ [Accessed 30 September 2026].