01
Write it and map it
Create a policy in one place and link it to the controls it satisfies across your frameworks. The same policy can answer ISO 27001 A.5.15 and SOC 2 CC6.1 at once, instead of living as a separate document per standard.
Write a policy, map it to the controls it satisfies, and have an approver sign it off. Each approval freezes a new version with the approver, the date, a changelog and a snapshot of what was covered at the time, so the binder you hand an auditor matches what was actually approved, not a document someone edited after the fact.
A policy moves from draft to approved, and every approval is recorded as its own version you can go back to.
Create a policy in one place and link it to the controls it satisfies across your frameworks. The same policy can answer ISO 27001 A.5.15 and SOC 2 CC6.1 at once, instead of living as a separate document per standard.
Assign the approver role for each policy and move it to needs-approval. Approving it captures a full snapshot, the approver, the timestamp and a changelog, and publishes that version.
Each approved version is frozen with who approved it, when, what changed and which controls it covered at that moment, so you can show an auditor the exact version that was in force on any date.
When a policy changes, it goes back to draft and the next approval creates the next version. Earlier versions stay intact and readable, so the full history of what you required, and when, is always there.
Four choices behind how policies work here, each one something you can check.
Every approved policy carries a version number like 1.2.1, and approving a change mints the next version automatically.
The approver, the approval date and a changelog are stored with every version, alongside a snapshot of the controls it covered at the time.
A policy links to the controls it satisfies across frameworks, so a single access-control policy can map to ISO 27001 and SOC 2 at once.
Superseded versions aren’t overwritten or deleted, so the version that was in force on any past date is still there to open.
Hosted in Switzerland by default, in German and English, with on-premise possible. Your data and evidence are yours and exportable in full at any time, with no lock-in.
Policies don’t live alone. Each one maps to the controls it satisfies, rolls into your coverage, and shows up in the audits that test it, all in the same workspace.
Map each policy to the controls it satisfies.
See how published policies roll up into coverage.
Show the approved version in force at the audit.
Draft a policy for a control, then review and insert.
Yes. Every policy carries a semantic version like 1.2.1, and each approval creates a new, frozen version with the approver, the date and a changelog. Earlier versions stay intact, so you can open the exact version that was in force at any point.
Each policy has an assigned approver role. When it’s approved, the approver and the timestamp are stored on that version, so every published policy carries a record of who signed it off and when.
Yes. A policy links to the controls it satisfies, and a single control can map across frameworks. So one access-control policy can answer ISO 27001 A.5.15 and SOC 2 CC6.1 at the same time, instead of being copied per standard.
In a shared drive, a policy is one file that gets edited in place, so “what was approved, and when” is a guess. Here, each approval freezes a numbered version with the approver, the date, a changelog and the controls it covered, and links the policy to the frameworks it satisfies, so the history is the record rather than something you reconstruct before an audit.
Swiss-hosted by default, in German and English, with on-premise possible. Your policies and their full version history are yours and exportable at any time, so there’s no lock-in.
Version your policies, map them to the controls they satisfy, and record who approved what, and when, so the policy you show an auditor is the one that was actually in force.