Skip to main content
Policies are the documented rules and procedures your organization follows to meet compliance requirements. Regentra provides a full policy management system — from drafting with templates to collecting signed acknowledgments from every employee.

​
Creating Policies from Templates

Regentra includes a library of pre-built policy templates tailored to each compliance framework. Templates cover common policies like:
  • Acceptable Use Policy
  • Access Control Policy
  • Incident Response Plan
  • Data Classification Policy
  • Business Continuity Plan
  • Password Management Policy
1

Navigate to Policies

Open the Compliance module and click Policies in the sidebar.
2

Click New Policy

Select New Policy and choose whether to start from a template or from scratch.
3

Select a template

Browse templates by framework or category. Each template includes boilerplate language adapted to the framework’s requirements.
4

Customize the content

Edit the template to match your organization’s specific environment, terminology, and procedures.
Templates are starting points, not final products. Always customize policy language to reflect how your organization actually operates. Auditors look for policies that match reality, not generic boilerplate.

​
Policy Editor

The policy editor supports both rich text and Markdown formatting. You can:
  • Structure content with headings, lists, and tables
  • Embed links to external resources or internal procedures
  • Add inline notes and callouts for reviewers
  • Preview the final formatted document before publishing

​
Policy Lifecycle

Every policy moves through a defined lifecycle:
Moving a policy backward in the lifecycle (e.g., from Approved back to Draft) is allowed. This is useful when an active policy needs significant revisions.

​
Separation of duties — self-approval is tracked, not blocked

Regentra tracks a separation-of-duties (SoD) signal on policy approval: it records who last edited a version’s content (lastContentAuthorId) and, when that same person approves the policy, flags the approval as a self-approval. Self-approval is allowed, not blocked. In a solo-admin or two-person MSP, the person who wrote the policy is often the only available Approver, and a hard block would leave the policy permanently stuck. Only Approver-tier roles can approve or activate a policy at all — that role gate is unchanged — but once someone with that role approves their own edit, the approval goes through and is recorded with a self-approval flag on the audit log, so the SoD signal is preserved for review even though the action itself isn’t stopped.
When you have more than one Approver available, route policy approvals to someone other than the author — that’s still the stronger control, and what most SOC 2 / ISO 27001 / HIPAA auditors expect to see as your default practice. The self-approval flag exists precisely so an auditor can see when and how often the exception was used.

​
Per-requirement applicability badges

Compliance programs vary by organization type — a requirement that only binds business associates doesn’t apply to a covered entity, and vice versa. Regentra surfaces this on each framework requirement directly. On any framework detail page (Compliance → Frameworks → [framework]), requirements that apply only to specific organizational roles render with an applicability badge — for example business-associate only or covered-entity only (other roles used across frameworks include merchant, service-provider, and multi-tenant-service-provider). Hover the badge for the long-form explanation. If the role does not match your org, mark the corresponding control N/A with a one-line justification.
The badges are a heads-up, not an auto-N/A. Auditors generally accept an N/A on a flagged requirement as long as the justification names the role mismatch — “we are not a clearinghouse” is sufficient.

​
Version History

Regentra maintains a complete version history for every policy. Each time a policy is updated and re-published, a new version is created.
  • View previous versions and compare changes
  • Track who made edits and when
  • Auditors can see the full history of policy evolution
  • Previous versions remain accessible even after new versions are published

​
Signature Campaigns

Signature campaigns let you send one or more policies to employees for formal acknowledgment. Campaigns are created from Campaigns in the sidebar, not from an individual policy’s detail page — see Acknowledgment Campaigns for the full walkthrough of building recipient lists, setting a due date, and sending.

​
Campaign Tracking and Reminders

The campaign dashboard shows real-time completion status:
  • Signed — employees who have reviewed and acknowledged the policy
  • Pending — employees who have not yet responded
  • Overdue — employees who have missed the deadline
Reminder emails go out automatically on a fixed schedule — 7 days before the deadline, 1 day before, and on the due date itself, then every 3rd day after the deadline (copying the recipient’s manager) until it’s signed. There’s no manual “send reminder now” button and the schedule isn’t user-configurable.
Completed signature records are stored as compliance evidence and can be attached to relevant controls. This creates a direct audit trail from framework requirement to policy to employee acknowledgment.