Stand up the access control before the audit starts.
Passing an audit assumes the control already exists and has been operating. If you are starting SOC 2, ISO 27001, or GDPR from scratch, Driply is the fastest way to put a real access control in place and start accruing the history you will be asked for.
- FFigma12 / 15Design
- GGitHub23 / 25Eng
- NNotion40 / 50Ops
Compliance work usually starts with a gap analysis that tells you what you already knew: access is granted ad hoc, nobody owns the decision, and there is no record. The controls have to exist and operate for a period before anyone can certify them. Driply is where you put that control. Build the register, give each tool an accountable owner, route requests through approval, give grants an expiry, and the evidence starts accruing from the day you switch it on rather than from the month you remember to start.
The gap between a policy and a control
Most small companies write the access policy long before they operate it. The document says access is approved by a manager, reviewed quarterly, and revoked on exit. The reality is a Slack message, no review, and an account that outlives the person.
That gap is what auditors find, and it is not fixed by better intentions. A control is only a control if it is the path of least resistance. If the compliant route is slower than the shortcut, people take the shortcut and the policy quietly becomes fiction.
The register first
Start from the catalog and add the tools you already run, or connect Google Workspace and let the roster and tools surface from real usage. Within an afternoon you have the inventory almost every framework opens by asking for.
Controls that people will actually use
Requests happen in Slack, approvals take one click, and the owner of the tool decides. The compliant route is the fast route, which is the only reliable way to make a control operate rather than exist.
The GDPR side too
Record each tool’s certifications, whether it processes personal data as a sub-processor, and where it hosts that data. That is the groundwork for Article 28 and Article 30, kept beside the tool instead of in a separate document that ages.
The result, A control that is real from day one, not a policy you hope nobody tests.
Start accruing history now, not the month before
An audit tests a period, not a moment. Turning the control on in month one and letting it run is materially cheaper than a scramble in month eleven, because the evidence is a by-product rather than a project, and because the observation window has already started.
The order that works: the register, then an owner per tool, then requests through approval, then expiry on grants that should not be permanent, then a review cadence. Each step is useful on its own, so you are never mid-migration with nothing to show, and the first two are available on every plan including Free.
What Driply is not: it does not write your policies, run your risk assessment, or manage the rest of the framework. It makes one control real and evidenced. Teams commonly pair it with a compliance platform that tracks the other controls, and export from Driply into it.
Driply documents and proves access. It doesn’t provision or revoke inside your tools, and by design never writes to them. You stay in control of the actual access.
Questions, answered.
- We haven’t started SOC 2 yet. Is Driply too early?
- It is the opposite. Turning the access control on before the observation window starts is exactly when it is cheapest, because the evidence accrues by itself instead of being reconstructed later.
- Which frameworks does this help with?
- Anything with an access control and a vendor inventory: SOC 2, ISO 27001, and the GDPR Article 28 and 30 obligations around sub-processors and data residency. The record is framework-agnostic; the export is what differs.
- Do we need a compliance platform as well?
- For the full framework, usually yes. Driply owns the access control and the tool register underneath it, and exports evidence into whatever platform or auditor you use.