Policies
Policies drafted in your real context, versioned, reviewed and signed off, the documented backbone of your program.
Policies are the written commitments that back your controls. Aegis writes the first draft for you and then manages the full lifecycle, authoring, versioning, approval and attestation, in one place.
Written in your context
When your program is materialized, Aegis generates a full set of policies, not generic templates, but documents written around your actual organization: your cloud providers, your data types, your workforce model and your data-residency choices. A retention policy for a fully remote team on Google Cloud and Azure reads differently from one for an on-prem enterprise, and Aegis writes the one that fits you.
Each policy still belongs to you: the draft is a strong starting point that a human owner reviews, edits and approves.
The policy lifecycle
Draft
Every generated policy starts as a draft. Edit it in a rich editor, or upload your own PDF if you already have an approved document.
Review & approve
Submit the policy for approval and choose an approver. While it waits, its status is needs review. The assigned approver accepts the changes, which publishes them, or denies them.
Publish
A published policy is the authoritative version. Publishing a new version supersedes the old one while preserving history.
Attest
Require employees to read and sign the policies that apply to them, so you can prove not just that a policy exists but that your people acknowledged it.
Approval is enforced
Every policy is published through approval, in every organisation; there is no setting to turn it off. The Aegis API enforces this, so it holds for API keys and integrations as well as the app:
- Publishing means submitting a version for approval. You choose an approver, and the policy is published when that approver accepts. Accepting is refused for anyone else, and setting a policy's status to published by editing it is refused.
- Choose someone other than yourself. You can submit to yourself only when you are the only person who can approve; Aegis records that as a self-approval. Approvers are active members whose role can update policies; NexusVoid staff who are members can approve too.
- Owners and admins can cancel a pending request. The approver can deny it. Either way the policy goes back to the status it had before it was submitted, and its live text is unchanged.
- Published text is frozen. Once a policy has been published, its current version can't be edited, even if you move the policy back to draft. The same applies to that version's PDF. Create a new version, edit it and submit it for approval.
- Regenerating a published policy creates a new version for you to review and submit; it never replaces the text that is in force. A policy that has never been published is regenerated in place.
- While a version is waiting for approval, it can't be edited or deleted, and the policy's status and approver can't be changed by editing the policy.
On the roadmap board, policy cards are locked for the same reason: they move through approval on the policy page.
Versioning
Policies are versioned. The current version is the authoritative one; older versions are retained so you can show an auditor how a policy evolved. When you need to make a change to a published policy, you create a new version rather than editing the record of what was in force, the audit trail stays intact.
Editor and PDF
Each policy can be maintained two ways:
- Editor view — a structured rich-text document you edit in place. This is the default for policies Aegis drafts.
- PDF view — upload an externally maintained PDF when you already have a signed-off document. Aegis shows the editor content when no PDF is attached, so you always see the real content.
Ownership and mapping
Every policy carries the metadata that makes it governable:
| Field | Purpose |
|---|---|
| Assignee | The person accountable for keeping the policy current |
| Approver | Who signs off on publication |
| Department | The part of the organization it governs |
| Review frequency & date | When it must next be reviewed |
| Mapped controls | The controls this policy backs, so policy work counts toward your program |
Because policies map to controls, publishing and maintaining them moves your framework coverage, they are part of the program, not a separate document library.
Next steps
Controls
The controls your policies implement.
Evidence & Tasks
Prove policies are read, followed and enforced.
Team & Access
Who can author, approve and attest.
Questionnaires
Your published policies power automated questionnaire answers.
Contact us
- Website: nexusvoidai.com
- LinkedIn: linkedin.com/company/nexusvoidai
- Email: ujwal@nexusvoidai.com