A policy says access must be removed when an employee leaves. HR closes the payroll record, IT gets a ticket the next morning, and nobody knows who removes access from the contractor portal. The policy sounds correct; the procedure still fails. A good policy programme resolves that gap before it becomes a recurring exception.

A policy is a decision; a procedure is the work

Write the rule first. Then say who owns it, what triggers it, what evidence shows it happened and how exceptions are approved. An access-control policy might define the company’s expectations; the offboarding procedure should tell the service desk which systems to check and who confirms completion. ISO/IEC 27001 and NIST controls are useful reference points when the customer’s needs are clear.

How CyberSeal makes policies fit the business

CyberSeal starts by reviewing existing documents and interviewing stakeholders. It maps gaps to relevant frameworks, drafts policies and operating procedures, and puts them through stakeholder validation before publication. The scope can include acceptable use, classification, supplier security, incident response, change management and offboarding. The team can translate the final decisions into shorter awareness material for the people who actually have to follow them.

Explore CyberSeal’s Managed Security Policy Services.

From discovery to delivery

The security policy lifecycle
  1. 1 Discovery
    Inventory policies and interview the people who run the process.
  2. 2 Gap analysis
    Compare current practice and documents with agreed requirements.
  3. 3 Drafting
    Write the rule, the procedure, and the evidence to keep.
  4. 4 Validation
    Walk through a real scenario and record stakeholder approval.
  5. 5 Publication
    Roll out the approved version and track communications.
  6. 6 Ongoing review
    Revisit the rule when tools, risks, or responsibilities change.

What CyberSeal onboarding looks like

Kickoff and scope. We start with a discovery workshop to understand the business, why you are updating the policies, and which teams or regions need to follow them. We agree which policies and procedures to tackle first, who owns each process, and who needs to approve the finished documents. A startup building its first policy set might begin with access control and incident reporting. A business preparing for an assessment might start with missing procedures and evidence.

Document review and interviews. Share current policies, procedures, process maps, relevant customer or audit requirements, and examples of the tickets or records your teams use. In stakeholder interviews, we trace how work actually gets done. For offboarding, that can mean asking HR who starts the request, IT who removes access, and application owners who is responsible for accounts outside the central directory.

Gap review and drafting. We review gaps with your team against the requirements agreed for the engagement, which may draw from ISO/IEC 27001, NIST, or SOC 2. For each priority gap, discuss who owns the decision, what the procedure needs to say, and what evidence will show it is followed. We draft around the systems and approval paths you already use and raise open decisions for your team to resolve.

Approval, rollout, and handover. We validate the draft with the people who will use it, work through their feedback, and route it for approval. Once approved, we support rollout to staff and can turn key changes into short awareness material. Agree where approved versions live, who maintains them, and how staff flag exceptions. Where ongoing management is in scope, we revisit policies as systems, risks, or requirements change.

What to check: Before approving a policy, hand it to someone who performs the task. If they cannot explain what they would do next, revise the procedure.

Practical details and examples

Identify the decisions that need a written rule

Start with three conversations: one with leadership about decisions that need a consistent standard, one with system owners about the actual way work happens, and one with employees about where current instructions leave them guessing. Then collect the relevant customer commitments and assessment requirements. A team building its first programme may need policies for access, acceptable use and incident reporting before it needs a large document catalogue. A company preparing for an audit may have good policies but incomplete evidence that people follow them.

For each proposed document, write down its audience and the event that makes it useful. An incident response procedure should help people who have just received a report. A data classification policy should help someone decide whether a file can go into a supplier portal or an AI tool. These are different needs and may require different formats. CyberSeal’s discovery and gap mapping give the customer a way to choose what to write first, while avoiding duplicated policies that use different terms for the same decision.

Example: Design an offboarding policy around the actual workflow

Imagine a business with employees, contractors and third-party support staff. HR knows when employees leave. A procurement manager might be the first to know when a vendor’s engagement ends. If the organisation only routes requests from HR, some accounts can remain active after the work has ended. Start by mapping who knows the end date for each group and which systems are outside central identity management. Ask whether system owners can see the request in time to act.

The resulting policy might say that access must be reviewed or removed when the relationship ends, according to the approved timetable. The procedure should tell the request owner where to file a ticket, which accounts to check, who approves an exception and where to record the result. Rehearse it with a fictitious departure and one system that cannot be disabled centrally. If nobody knows who owns that system, fix the ownership before rolling the procedure out. The same exercise often exposes gaps in supplier accounts and access review processes.

Evidence trail: Departure recorded → access removal ticket assigned → system owners confirm removal → remaining exceptions recorded for follow-up.

Draft, review and roll out with the customer

The team preparing a policy should show the customer which requirements it addresses and where a decision is still open. If a draft says privileged access needs stronger verification, confirm what the current identity tools support and what an interim control would look like. Include front-line owners in the review so the wording reflects the work they can actually perform. Leadership can then approve the rule and any exceptions with a clearer view of the operational cost and risk.

Once approved, publish one current version and make it easy to locate. Give each team a short explanation of what changed and what it needs to do differently. Where appropriate, translate policies into quick awareness content or a checklist a manager can use during onboarding. Record ownership, version and review date. If the organisation operates across regions, have the appropriate internal advisers confirm how local requirements affect the policy before approval. Reference frameworks inform the design; their names on a document do not prove that a control is implemented.

Keep policies useful between audits

Agree what triggers a review outside the normal schedule. Examples include adding a new cloud provider, adopting a tool that processes confidential data, changing a reporting channel or reorganising who approves access. Set a route for staff to report a rule that cannot be followed as written. For each exception, record what is different, who approved it, what interim measures apply and when the exception will be reconsidered. Over time, repeated exceptions can reveal that a policy or underlying process needs redesign.

During an ongoing policy review, check a small sample of real work. For offboarding, trace a few completed tickets to the systems they were meant to cover. For change management, check whether an emergency change was logged and reviewed afterwards. Discuss missing evidence with the owner before assuming the work was not done. The point is to learn whether policy, procedure and practice agree, then change the weakest part. If the engagement is project-based, agree who will continue those checks after handover.

What to ask for at handover

Ask for approved documents, the corresponding procedures, a list of owners, open decisions and a schedule for review. Confirm where staff will find the approved versions. The security lead should be able to pick one policy, identify an example of how it is used, and show the evidence someone would review. If that demonstration works, the document is much more likely to remain useful after the next audit.

Frequently asked questions

Can we start with just a few policies?

Yes. Prioritise the risks, customer commitments and upcoming assessments that affect the business first.

How is this different from GRC as a Service?

This engagement focuses on policies and operating procedures. A broader GRC programme also runs the risk register, governance reviews and compliance activities.

Authoritative references

Next step

Start with a review of the policies that cause the most questions or exceptions.

View Managed Security Policy Services