# Document who owns access revocation

An access boundary depends on several teams. A useful handover names who changes the source, who updates retrieval and who handles a stale result.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Follow one access removal from start to finish

Choose a realistic event, such as a staff member leaving a client account. The account owner removes access in the document system. An ingestion or identity process carries that change into retrieval. The application stops reusing affected answers. Support may need to explain why an old conversation no longer opens its sources.

Draw that chain with named systems and responsible roles. A general statement that "IT owns access" leaves too much unresolved. The document administrator may control source permissions but have no way to inspect the answer cache. The application team may operate the cache but have no authority to decide who should retain access.

Agree which system is authoritative for the access decision. Other copies should follow that source rather than become independent permission lists that drift over time.

## Define the promise the service can actually keep

State how quickly a confirmed source change should affect retrieval, stored answers and citation links. The target may differ between collections. A public handbook and a sensitive client workspace do not necessarily need the same mechanism.

Explain the conditions behind the target. If changes arrive through a scheduled job, document the schedule and what happens when the job fails. If the application checks access on each request, document what it does when that dependency is unavailable. Avoid describing a best-case observation as a guaranteed response time.

Include the way the team measures the delay. A dashboard that shows the ingestion worker is running does not show that a particular revocation has reached every serving layer. Retain a small test relationship that can be changed and checked without using real confidential data.

## Give operators a practical recovery path

The handover should explain how to identify the affected source, inspect its indexed permission version and prevent it from serving while the issue is investigated. Name the control used for containment and the role allowed to operate it.

Document the consequences of a full reindex or cache clear. These actions may increase load, remove useful diagnostic evidence or temporarily reduce search quality. They should not be the only instructions available for a single stale permission.

Include a worked support example. Show the request identifier, the source change time, the expected version and the place an operator checks the serving version. Keep the example synthetic and update it when the tooling changes.

## Make ownership survive the project team

Assign ownership of the access fixture, connector configuration, identity mapping and revocation monitoring. Store the runbook where the operating team already works. A document in the delivery team's private folder is not an effective handover.

Before accepting the handover, ask the receiving team to perform a revocation exercise without the original developer driving the keyboard. Observe where instructions are missing or rely on personal knowledge. Fix those gaps while the people who know the system are still available.

Finally, record which changes require another access review. A new document source, a different identity provider, a shared cache or a new export feature can alter the boundary even when the assistant's visible interface stays the same.

## Sources

- [OWASP: maintaining authorisation controls](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [Microsoft Learn: managing index changes](https://learn.microsoft.com/en-us/azure/search/search-howto-reindex)