How should organisations start building IT security policies and procedures when they do not have a mature program yet?

Start with the controls and behaviours that matter most to your environment, then use templates or frameworks to fill the gaps. Good policies should reflect how the organisation actually runs security, support compliance objectives, and give employees clear expectations. Treat them as living documents that can be scaled and updated as the business grows and its risk profile changes.

Start with the controls that match your operating reality

The right starting point is not a universal policy library, but the set of controls that reduce the most immediate risk in your environment. Focus first on access, authentication, logging, change control, and data handling where they are already part of how the business operates. That keeps the first policy set practical enough to adopt, rather than aspirational documents that never change behaviour.

Start small, but be specific. A policy that says “use strong access control” is less useful than one that defines who approves access, how exceptions are handled, what gets reviewed, and what evidence is retained. If the organisation cannot enforce a control yet, write the procedure around the current state and make the gap visible so it can be closed deliberately.

Use frameworks as scaffolding, not as the policy itself

Frameworks and templates help immature programs avoid blind spots, but they work best when they are translated into the organisation’s actual processes, systems, and accountability model. A good template gives you structure for core topics such as acceptable use, access management, incident response, backup, and vendor risk, but it should be trimmed to what the business actually uses. Overbuilding the first draft usually creates policy clutter, not security.

This is where a mature template can accelerate consistency. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful as a control catalogue when you need to decide which areas require formal treatment, while NIST Cybersecurity Framework 2.0 helps organise those controls into govern, identify, protect, detect, respond, and recover activities. For policy drafting that needs a simpler maturity lens, OWASP SAMM can help structure the security programme itself.

Make the first documents operational and maintainable

The first policies should be short enough that managers can use them and detailed enough that employees can follow them. Each one needs an owner, a review cycle, an exception path, and a clear link to procedure. Without those four elements, the document becomes static guidance instead of something the organisation can actually run.

Prioritise the policies that create repeatable decisions, such as who can grant access, how systems are configured, when incidents are escalated, and what must happen when someone joins, changes role, or leaves. That is also the point at which security becomes scalable: the policy should describe the decision standard, while the procedure describes the steps, forms, approvals, and records needed to execute it consistently.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP SAMM set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Policies must define access approval, review, and revocation decisions.
	CM-2 — Baseline Configuration	Early policies should anchor secure configuration and change control.
	IR-8 — Incident Response Plan	A starter security programme needs clear incident roles and escalation paths.
Recommendation — Define account approval, review, and revocation steps in the access policy. Document baseline configurations and required change-approval steps. Establish incident escalation and response responsibilities in writing.
NIST CSF 2.0	GV.PO-01 — Policies, processes, and procedures	The question is about starting the policy and procedure layer of a security programme.
	GV.OC-01 — Organizational Context	Policy scope should reflect how the organisation actually operates and its risk profile.
Recommendation — Create concise security policies, processes, and procedures tied to business operations. Base policy scope on business context, operating model, and risk appetite.
OWASP SAMM	Governance — Governance	A young programme needs a maturity structure for building repeatable security practices.
Recommendation — Use governance practices to set ownership, cadence, and policy maturity goals.

Practitioner Guidance

What to prioritise: Write the first version around the few decisions that most affect exposure, then expand only after the organisation can follow them consistently. If a policy will not change day-to-day behaviour, it is probably too broad or too early.

What to verify: Confirm that every policy has a named owner, a review cadence, an exception process, and a corresponding procedure or control owner. If those are missing, the policy will not survive the first exception or audit question.

What good looks like: The policy set should be small, understandable, and enforceable, with each document tied to a real operational workflow and a measurable control outcome. The best early-stage programmes are not the most complete, they are the ones people can actually use.

Practitioner takeaway: Start with enforceable basics, use frameworks to cover gaps, and treat the policy set as a living operating model rather than a one-time documentation exercise.