Access Evidence

Every serious assurance regime asks a version of the same question. ISO 27001 and SOC 2 ask it as a periodic access review — who has access to what, is it still appropriate, and can you show it. NIS2 asks it of your supply chain — who outside your organisation can reach your systems, and on what basis. Internal audit asks it after an incident — who could have, and who did.

They are all the same question: who can reach what, and under which entitlement.

The question is answerable, not reconstructed

In most estates this is a reconstruction exercise. Someone exports a list from the gateway, another from the identity provider, a third from a ticketing system, and correlates them by hand into a spreadsheet that is correct on the day it is produced and stale the following week.

Here it is a query, because access is not described in a report — it is held as the model the platform enforces from. The same records that decide whether a request is allowed are the records an auditor reads.

Why that distinction matters

A report can be wrong without anything breaking. An enforcement model cannot — if it were wrong, the wrong people would have access. Evidence drawn from the mechanism is evidence that was being tested continuously by use.

What an access review draws on

Question	Resource
Which parties exist, internal and external	GET /v1/consumers
Which consumer has access to which API or product, at which version and environment	GET /v1/subscriptions
What a subscription is granted — per operation, not “access to the API”	GET /v1/subscriptions/{id}/scopes, GET /v1/subscriptions/{id}/operations
Which entitlements exist, and who is delegated them	GET /v1/entitlements, GET /v1/entitlements/{id}/delegates
What a person can do, and through which applications	GET /v1/identities/{id}/entitlements, GET /v1/identities/{id}/clients
What an application can do, and who may act through it	GET /v1/clients/{id}/entitlements, GET /v1/clients/{id}/identities
What the operations are, and what each one does	GET /v1/apis/{id}/openApiSpecs, GET /v1/openapispecs/{id}/content
Which versions exist and which are deprecated	GET /v1/apis/{id}/versions
Which policies apply — rate limits, caching and the rest	GET /v1/apis/{id}/deploymentFeatures
Service-level terms in force	GET /v1/apis/{id}/openSlaSpecs, GET /v1/apis/{id}/versions/{major}/slas
Who approved this access, and when	GET /v1/subscriptions/{id}/approvalFlows, GET /v1/subscriptions/{id}/approvalFlows/{flowId}/approvals
Who approved a change to the API itself	GET /v1/apis/{id}/approvalFlows/{flowId}/approvals

Consumers, subscriptions, specifications, versions and policies are core; entitlements, identities and clients are the entitlements service. Each is an ordinary resource with a published contract in the marketplace, callable against your own tenant. Nothing here is a special audit export produced on request — it is what the platform is made of, which is why it cannot drift from what is actually enforced.

That includes security you never wrote. If a specification declares no scopes, the platform generates one per operation — and those are held in the entitlements service like any other, so they appear in the same answers.

Entitled to, and actually used

These resources answer who is entitled to reach what — the question a periodic access review is built around, and the one that has to be right for least privilege to mean anything.

That is the management plane: what has been granted, and — through approval flows — who agreed to it. Runtime access is a different thing. It is decided by the gateway, per request, per operation, against the entitlements resolved for that request.

What the gateway records on that path is narrower than a request log. Refused requests are recorded with the rule that refused them, the operation path and the source address. Where a service-level agreement defines a cost, consumption is metered per subscription, per API, per period. A record of each successful call — who called which operation at what time — is not held by the platform.

If your scope requires that level, it is a deployment decision rather than a feature. On Hybrid and Self-hosted the gateway runs on your own infrastructure, so request-level logging goes to whatever you already collect logs with. On PaaS the gateway runs on ours. Settle it early.

Questions this makes ordinary

• Who can call this operation? Not who can reach the API — who is entitled to the specific operation, which is the granularity an auditor actually asks about.
• What can this consumer do? Everything they are entitled to, across every API and version.
• Who approved this access, and when? Where access was granted through an approval flow, the flow records each decision and who made it. Access the platform grants on its own — such as a deployment subscribing its consumers automatically — carries no approval flow.
• Who is affected if this changes? Which consumers are on the version you are about to alter.

The last one is worth dwelling on. Most access questions are retrospective; that one is preventive, and it is the difference between discovering the consequence of a change and deciding it.

Least privilege is structural, not a policy

An access review usually finds over-provisioning, because access was granted at the level the tooling made convenient rather than the level the work required. Where entitlements are per operation and enforced at the gateway, a subscription cannot be used beyond what it was granted — there is no broader underlying permission that the policy merely asks consumers not to exercise.

That converts least privilege from something you attest to into something you can show. What remains for the review is whether each grant is still needed.

And it is recorded per application, not only per person. In most estates a person’s entitlements are independent of the application they are using, so the question “what may this person do through this application” has no answer to look up.

Here an entitlement is delegated to a client, and optionally to a person acting through that client — “this user holds this role through this application” is a record in its own right. So a review can read what each application was delegated, and what each person holds through it.

The same evidence is your exit

This is worth stating explicitly, because it is usually treated as a separate question and it is not.

The resources above are not a description of your access model — they are your access model. Which means the answer to “can we show an auditor who has access to what” and the answer to “could we take this to another platform” are the same calls.

Ports intact. The API specifications and service-level terms. OpenAPI and OpenSLA are open standards, and because the specification generates the running surface rather than documenting it, what you take is what produced your APIs. Your implementation was never here.

Ports as data. Consumers, subscriptions, entitlements — generated scopes included — identities and roles, versions and policies. Each is read as JSON in the shape its published contract describes. These are standard concepts, so none of it has to be redesigned and none of it touches your implementation. What differs is where it lands: rarely in one product. The same model is usually split across a gateway, an authorisation server, a developer portal and an approval workflow.

Does not port. That all of those refer to the same thing and stay in step. That is what the platform does rather than a file you can carry — elsewhere it is several components mapped together, and keeping that mapping true becomes your job.

Credentials are not part of the model

A client id and secret belong to the authorisation server that issued them, and no authorisation server accepts ones set by a foreign system. On any platform change the receiving side issues its own, and consumers switch to them. Passwords are a matter for the identity provider, not the API platform.

An exit you have to request from a supplier is a promise. One you can execute yourself, from the same API you use for your access review, is a property.

And because an access review recurs, the path stays exercised. An exit route used only at exit is untested by definition — it works on the day it is needed or it does not, and nobody finds out until then. A quarterly review calls the same resources for an entirely different reason, so by the time portability matters it has been proven repeatedly by people who were not thinking about leaving. That is a property of ordinary operation rather than a contingency that has to be maintained.

You also do not have to take it on trust before committing. The contract for every resource above is published in the marketplace and readable without an account, so you can see exactly what shape the answer takes — what a subscription record contains, what an entitlement looks like — before becoming a client. Calling them requires being one; knowing what you would get does not.

What Apiway does not evidence

Being precise about the boundary is part of being useful to an auditor.

The platform evidences access to your APIs: who may reach which operation, under which entitlement, and who approved it. It does not evidence what happened inside your implementation, what your data contains, or access granted by systems it does not front. Those remain yours, as described in What Apiway Governs.

Nothing on this page is a claim of certification against any framework. It describes the evidence the platform can produce; whether that evidence satisfies a given control is a matter for your auditor and your scope.