Policies and Procedures

Policies and procedures turn security from tribal knowledge into repeatable, enforceable practice. They define expected behavior, assign responsibility, and provide the evidence auditors require.

If it is not written down, you cannot consistently enforce or prove it.

Security documentation is layered:

• Policy: high-level intent and rules (the what and why).
• Standard: specific mandatory requirements.
• Procedure: step-by-step how-to.
• Guideline: recommended best practice (optional).

Keep the distinction clear:

• A policy states a rule: passwords must be at least 12 characters.
• A procedure explains how: the exact steps to set the password policy in the identity provider.

Policies are stable; procedures change as tools change.

Most programs include:

• Acceptable Use Policy.
• Access Control / Identity Policy.
• Data Classification and Handling.
• Incident Response Policy.
• Business Continuity / Disaster Recovery.

The AUP defines what users may and may not do with company systems and data. It covers email, internet, devices, and consequences for violations, and is usually acknowledged at onboarding.

An access control policy codifies least privilege and review cadence.

• How access is requested and approved.
• Role definitions and segregation of duties.
• How often access is reviewed and revoked (e.g. on offboarding).

This policy defines how the organization detects, reports, and handles security incidents. It names roles, escalation paths, and communication rules so a crisis follows a plan rather than improvisation.

Every policy needs an owner accountable for keeping it current, and clearly assigned responsibilities. Without ownership, documents drift out of date and lose authority.

• Owner approves and maintains the document.
• Stakeholders implement and follow it.

Documents must be formally approved and version-controlled.

• Record author, approver, approval date, and version number.
• Track changes so auditors see the history.
• Set a review cycle, typically annual.

A policy nobody reads is worthless. Distribute documents, train staff, and collect acknowledgements. Awareness turns written rules into actual behavior and provides evidence of enforcement.

Policies need teeth. Define consequences for violations and back them with technical controls where possible (e.g. enforce the password standard in the IdP, not just on paper). Consistent enforcement keeps policy credible.

Tell a policy from a procedure.

Documentation makes security repeatable and provable:

• Use the hierarchy: policy, standard, procedure, guideline.
• Policies state rules; procedures give steps.
• Assign owners, approve, version, and review regularly.
• Communicate, train, and enforce to make documents real.