Policies and procedures

Introduction

Policies describe intent. They say what the company believes, what standard it is trying to meet and what behaviour is expected.

Procedures describe how the policy is carried out. They should be practical and capable of producing evidence.

This distinction matters for startups. A policy can be short and directional. A procedure needs to explain what actually happens. Evidence proves that the procedure is followed.

Why they matter early

Policies and procedures can feel too formal for a small team, but they become useful very quickly. They help new staff understand how the company works. They help agents understand the operating model. They help customers see that controls are deliberate rather than improvised.

They also make sales easier. Prospective customers often ask how access is approved, how incidents are handled, how data is protected and how changes are controlled. A lightweight policy backed by a real procedure is far better than a confident answer with no evidence.

Bootstrap versus state-dependent policy

Some governance should be created as soon as the company starts because it gives people and agents a place to record decisions, evidence and risk. A document management policy is a good example: it can be created without knowing the final product architecture because every later policy, procedure, decision record and review depends on document control.

Other policies should match the current operating state. A device policy should not pretend Intune, Company Portal, Defender or company-owned devices are in place if they are not. Instead, the company should record the current stance and the trigger that will make the policy required. As soon as BYOD with Intune is introduced, the BYOD and endpoint policy becomes necessary. As soon as company-owned devices are introduced, the policy must mature again.

The useful agent behaviour is:

• Create always-needed governance artefacts immediately.
• Inspect the current state before creating state-dependent policies.
• Record deferred policy triggers where the capability does not exist yet.
• Raise a risk where the capability exists but the matching policy, procedure or evidence does not.

ISO 27001 as a baseline

ISO 27001 is a good baseline for deciding which policies are needed. The goal is not early certification. The value is that ISO 27001 gives a recognised structure for thinking about information security, access control, suppliers, incidents, continuity, assets and evidence.

The company can use ISO 27001 as a map without pretending it is ready for certification. That keeps the policy set grounded in a recognised framework while staying pragmatic.

Minimum early policies

• Document management policy: defines how controlled documents are created, reviewed, approved,

versioned, published, retired and evidenced.

• Data classification policy: defines the information classes the company uses and the handling

expectations for each class.

• Access control policy: defines how users, administrators, service accounts and privileged roles

are requested, approved, reviewed and removed.

• Change control policy: defines how changes are planned, reviewed, tested, approved and traced

without creating unnecessary friction for a small team.

• Data protection policy: defines the company's intent for lawful, fair and transparent handling of

personal data.

• GDPR request procedure: defines how privacy requests, data subject requests, complaints and

customer/controller instructions are received, logged, owned, evidenced and closed.

• Logging policy: defines what should be logged, what must not be logged and the requirement that

PII, secrets and credentials are not written into logs.

• Secrets and certificate policy: defines how secrets, certificates, keys and credentials are

issued, stored, rotated, revoked and audited.

• Incident response policy: defines how incidents are reported, coordinated, communicated, resolved

and reviewed.

• Backup and retention policy: defines what is backed up, how long data is retained, how restore is

tested and how deletion obligations are handled.

• Backup data procedure: defines restore permissions, retention, deletion limitations, encryption,

key custody, decryption approval and decryption alerting where backups may contain personal or sensitive data.

• Supplier and processor policy: defines how vendors, SaaS tools, processors and sub-processors are

assessed, approved, reviewed and retired.

• Device and endpoint policy: defines the minimum security stance for company-owned devices, BYOD

and devices used for privileged access.

Each policy should have at least one procedure that can be evidenced once the related operating capability exists. Where the capability does not exist yet, record the trigger for creating the procedure.

Run governance bootstrap loop to decide which artefacts should be created immediately and which state-dependent policies should be deferred with a trigger. Use policy register to record policy status, ownership, review dates and deferred triggers.

Document management policy

A document management policy is easy to overlook, but it is central to an ISO-aligned control environment. ISO is not only interested in whether policies exist. It also expects evidence that policies are controlled, reviewed, approved, available to the right people and kept up to date.

The policy should define:

• Where controlled documents live.
• Who owns each document.
• Who reviews and approves each document.
• How version history is retained.
• How review dates are tracked.
• How obsolete documents are retired.
• How staff know which version is current.
• How exceptions and accepted risks are recorded.
• How evidence of review and approval is kept.

This responsibility should be shared. It should not sit with one person who becomes the policy bottleneck. AI can draft and improve policy text, but people need to read it, challenge it, approve it and take responsibility for operating it. A practical startup model is to assign accountable owners by area: engineering for change and release controls, security or technical leadership for access and secrets, operations for incident coordination, and data protection ownership for privacy and data handling.

The evidence can be simple:

• Document owner recorded in the document metadata.
• Version history or source-control history.
• Pull request or approval record.
• Review date and next review date.
• Meeting note or decision record for material changes.
• Published location in SharePoint, wiki or source control.
• Evidence that staff were told about material policy changes.

Data classification

Data classification should be one of the early pieces of governance because it defines what the company considers important. This guidance can be used to create a policy, but it is not the policy itself. Without classification, every document, database, backup, log file and support ticket is treated by habit rather than by risk.

The policy does not need to be complicated. A simple starting model is enough:

Compartment tags can then restrict access further, for example HR-only, finance-only, legal-privilege or customer-specific data. The important point is that classification should drive controls: who can access the data, where it can be stored, whether it can be sent to AI tools, how it is backed up, how long it is retained and whether it can appear in logs.

Detailed evidence examples

Evidence does not need to be complicated. It can be:

• An access request and approval.
• A pull request showing a production change.
• A backup restore test record.
• An incident timeline.
• A supplier review note.
• A decision record accepting a known risk.
• A screenshot or export from a system showing that a control exists.
• A classified data inventory or example of labelled documents.

How this evolves as the company grows

• At company setup, create the document-management stance, data classification and basic governance home early.

• At POC, keep policies lightweight but make repository, access, secrets, logging and decision-record expectations explicit.

• Before Pilot, policies and procedures need to match real data handling, GDPR requests, device posture and support paths.

• At Production and beyond, policy evidence, review dates, approvals and ownership become customer and ISO-style assurance.

What an agent should look for

• Is policy intent backed by procedure?

• Can the procedure produce evidence?

• Who reviews and approves controlled documents?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.