Vanta access reviews: why 'connected' is not 'reviewed'

Compliance automation platforms like Vanta, Drata and Sprinto have made a genuine improvement to how companies manage their ISO 27001 and SOC 2 programmes. They connect to systems, pull user lists, and make evidence collection faster and more consistent than a manual spreadsheet-and-screenshot approach. But there is a persistent and consequential misunderstanding about what these platforms do during access reviews - and it surfaces in audit rooms with some regularity.

When Vanta shows a green tick next to an access review integration, it means the integration is connected and the user data is being ingested. It does not mean a human being has looked at the user list, made a decision about who should and should not have access, and recorded that decision. An auditor reviewing your access review evidence does not want to see a Vanta dashboard. They want to see evidence that a person with authority over the system made a judgement call and signed off.

What an access review actually is

The underlying requirement - in ISO 27001 Annex A control A.8.2 on privileged access rights and A.8.3 on information access restriction, as well as the equivalent SOC 2 common criteria - is that user access is periodically reviewed and that inappropriate access is removed. The word "reviewed" has a specific meaning in this context. It means:

• A person with appropriate authority examined the access that exists.
• That person made an active decision for each account: the access is appropriate and should be retained, or the access should be modified or removed.
• That decision is recorded.
• Where changes were needed, they happened and were recorded.

None of those four elements are provided by a connected integration. Vanta can show you the list. It cannot make the decision, record the decision, or verify that the decision led to action. All three of those require a human, and the evidence must show that the human acted.

What auditors actually ask for

In a certification or surveillance audit, the auditor will ask about access reviews with questions along these lines:

"Can you walk me through how you conduct access reviews?"

A response that describes the Vanta integration, shows the connected systems, and demonstrates that user lists are being pulled will prompt a follow-up: "And then what? How do you record who reviewed it and what the outcome was?"

The answers that satisfy an auditor involve:

A recorded review artefact. This might be a Vanta review task that was completed with reviewer names and dates - Vanta does have this functionality, but it requires using the review workflow, not just having the integration connected. It might be a spreadsheet with a dated completion record. It might be a Jira ticket or a Confluence page with a sign-off. The form matters less than the content: who reviewed it, when, what systems were covered, and what decisions were made.

Evidence of decisions, not just a list. The output of a review cannot just be the exported user list. There needs to be some record of the decision against each account, or at minimum a record that the reviewer confirmed all accounts were appropriate and a list of accounts that were removed as a result of the review.

Follow-through on changes. If the review identified access that should be removed, there should be a record that it was removed - a ticket, a system change log, a confirmation in the review artefact. Identifying an issue and not acting on it is a control failure. Identifying an issue, acting on it, but not recording that it was addressed is an evidence failure.

Consistent scope. The review should cover the systems that the ISMS identifies as in-scope assets - not just the systems that happen to have Vanta integrations. A common gap is that the Vanta integration covers the main SaaS applications but misses the cloud console, the code repository, or internal tooling that also has access to production data.

The gap in practice

Consider an illustrative scenario: a SaaS company prepares for its ISO 27001 surveillance audit and points to Vanta as evidence that access reviews are in place. The Vanta dashboard shows all integrations connected, green status across the board, and a record that access review tasks were created.

The auditor asks to see a completed access review for the production AWS environment. The company shows that Vanta is integrated with AWS IAM and that a review task was created in the previous quarter. The auditor asks who completed the review, what they found, and what changed as a result. The company cannot produce a record of a named person signing off. The Vanta task was created and auto-closed, or was closed without the reviewer documenting their findings.

This results in a nonconformity against the access review control. The technical integration is working correctly. The compliance process around it is not.

How to make Vanta access reviews audit-ready

The fix is not complicated, but it requires treating the Vanta review workflow as a process that needs a human owner, not a system that completes itself once integrated.

Assign named reviewers. Each system in scope for access review should have a named person responsible for completing the review - typically the system owner or the relevant team lead. That person's name should appear on the completed review record.

Use the review completion workflow properly. Vanta's access review feature allows reviewers to approve, flag or remove individual users within the platform and to record a completion date. If you are using Vanta's review functionality, use it through to completion - do not mark a review complete without the reviewer having gone through the user list.

Document the exception handling. For accounts that the reviewer flagged as needing removal or modification, there should be a corresponding ticket or action record showing that the change was made. Link it to the review record.

Review out-of-Vanta-scope systems in the same cycle. If your ISMS scope includes systems without a Vanta integration - on-premises servers, legacy internal tooling, a code repository that is not connected - those need to be reviewed on the same schedule and the evidence stored alongside the Vanta-generated evidence. An auditor's scope of review includes all systems in your ISMS, not just the ones with green ticks.

Set a consistent cadence and stick to it. Access reviews should happen at a frequency proportionate to the risk - typically quarterly for privileged access, annually for standard access is a reasonable baseline. The reviews should happen at approximately the same interval. A review that happens 9 months after the previous one and 3 months before the audit is not evidence of a consistent programme.

What the platform does well

None of this is a criticism of compliance automation platforms. The integration layer, the evidence collection, the automated screenshots and the centralised evidence repository are all genuinely valuable. They reduce the manual overhead of running an ISO 27001 programme and make it harder for things to fall through the gaps.

The value of a platform like Vanta is in aggregating the raw data and creating the structure for the review programme to happen consistently. The actual review - the human judgement about whether access is appropriate - is not something any platform can automate. The platform is the infrastructure. The process is still yours.

Audit findings against access reviews almost always come down to a misunderstanding of this boundary: the team assumed the platform was doing more than it was, and did not build the human review process that sits on top of the integration.

Where Kellwick fits

Kellwick works with companies who are already using Vanta, Drata or Sprinto but have found that their compliance programme does not hold up under auditor scrutiny. If your access reviews are producing green dashboards but not audit-ready evidence, see how Kellwick can help you get the process right.