Security policy and governance
Write or review security policy that matches how your organization actually operates, with each statement mapped to the control meant to enforce it.
What we review
- Current policy inventory: What written policy exists today, when it was last reviewed, who owns it and whether anyone follows it.
- Operating reality: How the organization actually works, so the policy describes achievable practice rather than an aspiration nobody meets.
- Access and identity governance: How accounts, privilege, joiners, movers and leavers are meant to be handled, and who approves exceptions.
- Change and release governance: What must be reviewed, approved, tested and reversible before it reaches production.
- Data handling: Classification, retention, storage locations and third-party sharing, described in terms your team can apply.
- Incident and recovery governance: Who decides, who communicates, what gets recorded and what triggers escalation.
- Third-party and vendor governance: How external access is requested, approved, bounded and ended.
- Policy-to-configuration mapping: For each significant statement, the platform control that enforces it, and whether it currently does.
Deliverables
- Policy set: Written policy documents in your organization's language, scoped to what you actually operate.
- Policy-to-control map: Each significant statement linked to the platform control meant to enforce it, with its current state recorded.
- Gap register: Where written policy and enforced configuration disagree today, prioritized by risk rather than by ease of fixing.
- Exception process: How a documented, time-bounded exception is requested and approved, so reality does not quietly drift from the document.
- Review schedule: What gets revisited, how often, and what event forces an out-of-cycle review.
- Questionnaire-ready summary: A plain summary your team can reuse when a client or insurer asks how something is governed.
Engagement boundaries
- This work produces written policy and a mapping to technical controls. It does not certify compliance against any standard, framework or regulatory requirement.
- It is not legal advice. Where a legal or regulatory obligation applies to your organization, your counsel or a qualified auditor remains the authority.
- Policy is written to match how you operate. We do not supply a generic template with your name on it.
- Where written policy and live configuration disagree, both are reported. We do not quietly rewrite policy to match a weak control.
- Implementing the technical controls a policy calls for is separate work, scoped separately.
- Verified findings are kept separate from assumptions and statements we could not test.
- We do not draft policy that commits your organization to a capability it does not have.
- Policy ownership stays with you. An external document nobody internally owns will not survive its first review cycle.
Questions before the work starts
Can you just give us a policy template?
A generic template with your logo on it will not survive a serious client review, and it will not describe how you actually work. Policy here is written against your real operating practice and mapped to the controls that enforce it. If a template is genuinely all you need, say so and we will tell you honestly whether this engagement is worth the cost.
Does this make us compliant?
No, and anyone promising otherwise is overselling. This produces written policy and an honest map of where enforcement matches it. Certification against a framework requires a qualified auditor, and legal obligations require legal advice. What you get is a defensible, accurate picture of what is governed.
What if our configuration does not match our policy?
That is one of the more useful findings the work produces, and it is reported plainly. You then decide whether to change the configuration or change the policy. What does not happen is silently weakening the document to make a gap disappear.
Who needs to be involved from our side?
Someone who knows how the work actually gets done, and someone who can approve what the organization commits to. Policy written only with IT tends to miss real practice; policy written only with management tends to miss what is achievable.
How do we keep it current?
The deliverable includes an owner, a review schedule and an exception process. Policy drifts when there is no named owner and no trigger for revisiting it. That structure matters more than the polish of the document.
The platforms this work covers
Written policy is mapped to the platforms that have to enforce it, so the document and the configuration do not drift apart.
- Microsoft 365 and Entra ID
- Microsoft Azure
- Amazon Web Services
- Cloudflare
- Cisco
- Palo Alto Networks
- Fortinet FortiGate
- Check Point
- F5
- Data centre and virtualization
Audits available
- Policy-to-configuration audit: where the written policy and the enforced configuration disagree.
Other ways we can help
Engagements are often scoped together; these are the closest neighbours to this one.
Need written policy that matches how you actually operate?
Share what policy exists today, what prompted the need, and any client or insurer requirement driving it. The first conversation establishes whether you need policy written, reviewed, or simply reconciled with your current configuration.