Proving a path to the data is not the same as taking it
Reading a real person’s records is one of the three actions that stop and wait for your written approval. That is a property of how the platform runs rather than a policy written about it — an engagement proves the path and stops there, so in the ordinary case there is nothing of your customers’ for it to hold.
What it holds
Five things, and four of them describe your systems
An assessment cannot be evidence-bearing and hold nothing. What it holds is the material a finding is made of, which is a description of how your systems behave rather than a copy of what is inside them.
| What an engagement holds | Why, and for how long |
|---|---|
| The scope you authorised | Targets, classes, roles, and for the classes that need one the movement boundary. It is the document the engagement is measured against, and it is retained with the engagement record. |
| The evidence for each finding | The request as sent and the response as returned, with the part that proves the defect marked. A finding without it is an assertion, which is why this is the one thing an engagement necessarily keeps. |
| What the targets disclosed | Versions, configuration, routes and the other material discovery returns. It is what the report is written from, and it describes your systems rather than your customers. |
| Source code, where a review is in scope | Held while the engagement is active and deleted after thirty days of inactivity. Where the review runs inside your own pipeline the source never leaves it at all. |
| Credentials you issued for testing | The accounts you created for the engagement, for the roles whose boundaries are being tested. Yours to revoke at the end, and worth revoking. |
The scope you authorised
- Why, and for how long
- Targets, classes, roles, and for the classes that need one the movement boundary. It is the document the engagement is measured against, and it is retained with the engagement record.
The evidence for each finding
- Why, and for how long
- The request as sent and the response as returned, with the part that proves the defect marked. A finding without it is an assertion, which is why this is the one thing an engagement necessarily keeps.
What the targets disclosed
- Why, and for how long
- Versions, configuration, routes and the other material discovery returns. It is what the report is written from, and it describes your systems rather than your customers.
Source code, where a review is in scope
- Why, and for how long
- Held while the engagement is active and deleted after thirty days of inactivity. Where the review runs inside your own pipeline the source never leaves it at all.
Credentials you issued for testing
- Why, and for how long
- The accounts you created for the engagement, for the roles whose boundaries are being tested. Yours to revoke at the end, and worth revoking.
The gate that does the work
Why the default is that we do not have it
An authorisation defect is proved by reaching one record that belongs to somebody else. Enumerating the rest of them proves nothing further and changes what the engagement is holding, so it is a separate act behind a separate written approval. The same line runs through every class: a cloud finding is a permission proved by making one call, not by decrypting a production dataset; an API finding is a pair of requests, not an export.
Where you do authorise the next step — because the finding genuinely needs it, or because your own investigation does — the report says which findings went that far. That is worth more to a reviewer than a blanket assurance, because it is checkable.
Where it sits
Region, and whether anything is deployed
You choose the region: India, the European Union, the United States, or Singapore and Asia-Pacific. For an entity inside the scope of CERT-In Directions No. 20(3)/2022-CERT-In — issued 28 April 2022, effective 27 June 2022, and requiring 180 days of rolling ICT logs within Indian jurisdiction — that choice is a compliance decision rather than a preference.
External and application testing need nothing deployed inside your network at all. Internal network testing needs a position inside it, on your own infrastructure or in your own cloud tenancy. Deployment and residency sets out all three shapes and what is agreed before each.
Send us your diligence questionnaire before the commercial conversation
It is the sensible order, and the answers are the same either way. Where something here does not cover what your security team needs to know, ask — a gap is better named than guessed at.