Policy Management
Policies are the written backbone of your compliance program. Claw GRC manages the full policy lifecycle — from drafting through approval, publication, annual review, and version archiving.
Policy Lifecycle
Every policy in Claw GRC moves through a defined lifecycle. The lifecycle ensures that policies are reviewed and approved before they're active in your compliance program, and that outdated versions are archived rather than deleted (preserving the audit trail).
| Status | Description | Compliance Impact |
|---|---|---|
| draft | Policy is being written. Not yet visible to non-authors. Not linked to framework controls. | No impact |
| in_review | Policy has been submitted for review. Assigned reviewers are notified. Comments can be added. | No impact |
| approved | Reviewer has approved the policy. Awaiting publication by policy owner. | No impact |
| published | Policy is active. Counts as evidence for linked controls. Employees can be assigned to acknowledge. | Evidence active |
| archived | Policy has been superseded or retired. Preserved in version history for audit trail continuity. | Archived |
Only published policies count as evidence
A policy indraft, in_review, or approved status does not satisfy framework controls. The policy must be in published status with a current review date to count as fresh evidence.The 12 Policy Types
When creating a policy, you select a type that determines which framework controls it's eligible to satisfy. The platform ships with 12 standard policy types, each with a default template and pre-mapped control links.
| Policy Type | Description | Key Frameworks |
|---|---|---|
| information_security | Master information security policy — defines the organization's overall security program and governance structure | SOC 2, ISO 27001 |
| access_control | Rules for granting, reviewing, revoking access — covering least privilege, MFA, privileged access management | All frameworks |
| incident_response | Procedures for detecting, classifying, responding to, and post-mortems on security incidents | SOC 2, NIST |
| change_management | Processes for approving, testing, and deploying system changes — infrastructure and application | SOC 2, ISO 27001 |
| data_classification | Data categorization scheme, handling requirements by classification level, retention and disposal rules | SOC 2, HIPAA |
| vendor_management | Third-party risk assessment process, contract requirements, ongoing monitoring standards | SOC 2, ISO 27001 |
| business_continuity | Disaster recovery planning, RTO/RPO targets, backup procedures, and business continuity plan | SOC 2, ISO 27001 |
| acceptable_use | Rules for employee use of company systems, data, and technology resources | ISO 27001, HIPAA |
| ai_governance | AI system development standards, deployment approval process, monitoring requirements, and agent behavior policies | EU AI Act, ISO 42001 |
| privacy | Personal data collection, processing, retention, and disclosure practices aligned with GDPR/CCPA/HIPAA | HIPAA, GDPR |
| vulnerability_management | Vulnerability scanning schedule, severity-based remediation SLAs, patch management procedures | SOC 2, FedRAMP |
| cryptography | Approved encryption algorithms, key management procedures, certificate lifecycle management | ISO 27001, FedRAMP |
Assigning Policy Owners
Every policy must have an owner — the team member responsible for maintaining the policy, scheduling reviews, and ensuring it stays current. Assigning an owner enables:
- Automated review reminders 30, 14, and 7 days before the next review date
- Escalation notifications if a review is overdue
- Accountability in the audit trail for all changes
- Dashboard filter: "My Policies" shows all policies the current user owns
To assign or change a policy owner, open the policy and click the owner field in the top-right metadata panel. Only Admin and Compliance role users can be assigned as policy owners.
Review Schedules
Each policy has a Next Review Date that determines when the policy should be re-evaluated and re-approved. Most compliance frameworks (SOC 2, ISO 27001) require annual policy reviews. Claw GRC enforces this through the evidence freshness system — a policy with a review date older than 365 days is treated as stale evidence.
Setting up a review schedule
- Open the policy detail view
- Click Schedule Review in the metadata panel
- Select the review interval (annually, semi-annually, quarterly)
- Choose the review date
- Assign a reviewer (can be different from the owner)
- Click Save Schedule
When the review date arrives, the policy owner and reviewer receive notifications. The review process creates a new draft version, which goes through the fulldraft → in_review → approved → published lifecycle. The previous version is automatically archived when the new version is published.
Version History
Claw GRC maintains a complete version history for every policy. When a policy is revised and re-published, the previous version is archived with:
- The exact text of the previous version (immutable)
- The date it was published and archived
- Who approved and published each version
- A SHA-256 hash of the document content for integrity verification
Auditors can request a specific policy version from any point in time. Version history is accessible from the policy detail view under the History tab.
Use version history to demonstrate policy improvement
Auditors reviewing your SOC 2 or ISO 27001 audit will want to see that policies are actively maintained, not just created once and forgotten. The version history is a powerful demonstration of operational security maturity.Linking Policies to Frameworks
Published policies count as evidence for framework controls. To link a policy to controls:
- Open the policy detail view
- Click the Linked Controls tab
- Click Add Control Link
- Search for controls by name or framework
- Select the controls this policy satisfies and click Link
When a policy has a review date in the future, it counts as fresh evidence for all linked controls. The platform automatically suggests control links based on the policy type — for example, an access_control policy will suggest linking to all access management controls across your active frameworks.