A compliance platform asks for read access to your cloud, identity provider, code host, and more. Review it as you would any vendor with sensitive access: check its own assurance reports, the exact scopes it requests, how credentials are stored, what data it keeps, and how you can revoke it quickly.
The irony worth stating
Compliance tools exist to prove you manage risk, and they themselves become a concentrated source of risk. A single account can see how your whole environment is configured. If that account is compromised, an attacker gets a map. Treat the purchase as a security decision first.
What to review
Assurance reports. Ask for the vendor's current attestation or certification and read the scope. Do not stop at the logo. How to read a vendor SOC 2 report covers what to look for. Also check the report period and any exceptions.
Scopes requested. For each integration, list the permissions. Prefer read only roles. Reject write permissions unless you understand why they are needed. Where possible, restrict to audit scope accounts and projects.
Credential handling. Is access via short lived tokens, role assumption, or stored keys? How are stored secrets protected, and who at the vendor can see them?
Data stored. Does the platform copy configuration only, or content? Does it store personal data of your staff? Where and for how long? Which subprocessors are involved?
Access control. Does it support single sign on, MFA, role based permissions, and an audit log of who did what?
Incident handling. How will they tell you if they are breached, and within what time? Check the contract.
How to reduce your own exposure
- Create dedicated read only roles for the platform, not shared admin accounts.
- Record every integration and its owner in your vendor list.
- Review granted access each quarter.
- Know the steps to revoke access quickly, and rehearse them once.
- Enforce single sign on and MFA for platform users.
Include the platform in your own program
Add the vendor to your register with a risk tier. It is a critical supplier because of what it can see. See how to tier vendors by risk.
What a simple approach looks like
If this review feels heavy for your size, note that a spreadsheet and shared folder have a smaller exposure footprint. It is a legitimate point in favour of staying light until the volume of work justifies a platform.
A short pre connection checklist
Before you click connect, run through these in about an hour:
- Read the vendor's security page and attestation scope.
- Compare each requested permission against what the control needs.
- Create the dedicated role, with a clear name, so it is easy to spot in your logs.
- Turn on logging for that role, and confirm you can see its activity.
- Record the integration in your vendor register with an owner and review date.
Doing this once gives you a repeatable pattern for every future integration.
Where Safeguard fits
Safeguard provides compliance and evidence automation, and its scanning runs from the free tool at gold.safeguard.sh/scan with no account connection, so you can look before granting any access.
Quick check
Should integrations be read only?
Wherever possible. Question any write permission and ask why it is needed.
Is the vendor's SOC 2 report enough?
It is one input. Also check scope, period, exceptions, and the access you are granting.
Last reviewed: 19 October 2026.
