Quick answer
In OptiTech, policy edits happen in a draft that's linked to your live data: before publishing, you see which controls reference the policy, which framework requirements it backs, and whether the change will trigger re-acknowledgment by employees. You're previewing the blast radius against your real compliance program, not editing a Word file in the dark.
Why previewing against real data matters
A policy isn't standalone prose; it's load-bearing. Your access control policy is mapped to framework requirements, referenced by controls, cited in questionnaire answers, and signed by employees. Change it carelessly and you can:
- Remove a commitment a mapped requirement depends on, silently weakening framework coverage.
- Contradict an automated check that still enforces the old rule.
- Trigger a company-wide re-signing for what was meant as a typo fix.
Editing in a disconnected document means discovering these effects after publication. The draft preview surfaces them before.
The preview workflow
- Open a draft of the published policy. The published version stays live and unchanged; see drafting changes separately.
- Edit, and watch the impact panel. It lists mapped requirements, referencing controls, and dependent documents, flagging which ones your edit touches.
- Classify the change. Editorial changes publish without re-acknowledgment; material changes trigger employee re-signing and a note in the version history.
- Route for review. The policy owner or reviewer approves, and publication is logged with author, approver, and diff.
The same principle for controls
Control changes get the equivalent treatment: adjusting a check's threshold or a control's mapping shows you, before saving, which frameworks and statuses will move. For that workflow, see testing control changes before rollout. The common rule: in a system your auditor relies on, nothing should change blind.
Get a personalized walkthrough of automated compliance for your team. No commitment required.