Security Governance & Leadership

Ross Moore

Feb 6, 2026 • 8 min read

Digital fortress with glowing network connections

Part 1 of a series on creating information security policies

Contents

Security Starts at the Top (or, Governance Makes or Breaks Your Security Program)
Disclaimer
Why Governance Comes First
The Information Security Policy: Setting the Tone
Risk Management: Replace Guesswork with Discipline
Roles and Responsibilities: Eliminating the Accountability Gap
What Auditors Look For
Common Pitfalls to Avoid
Governance as a Force Multiplier
Afterword about Infosec Policy and Infosec Policies
Resources

Security Starts at the Top (or, Governance Makes or Breaks Your Security Program)

Security programs shouldn’t be tied to a specific tool or control. They need someone to own the risk. Firewalls expire, policies gather dust, controls erode, not because of maliciousness or incompetence, but because governance was either not firmly established, or because it lost accountability.

ISO 27001 and SOC 2 both recognize this reality. They differ in structure and emphasis, but both begin with the same foundational assumption: information security is a management responsibility before it is a technical one. Governance sets direction, establishes accountability, and ensures that security decisions are made deliberately rather than reactively.

This first month focuses on the policies that anchor the entire security program: information security governance, risk management, and clearly defined roles and responsibilities. Without these, every other policy becomes harder to justify, harder to enforce, harder to defend.

Disclaimer

Hear ye, hear ye! Be it known unto all who peruseth this lowly scrivening that this author, though steeped in the arts of information security, is neither auditor, attorney, barrister, counselor, nor any other sworn keeper of royal law. These words are penned in good faith and offered for enlightenment and mirth, not as binding decree nor legal writ.

Shouldst thou require counsel of a lawful, legal, legitimate, licit, sanctioned or otherwise authoritative nature, get thee hence with all due speed to a licensed solicitor or other learned scribe of relevant and pertinent statutes. For, verily, the author claimeth none liability shouldst thine compliance dragons awaken or thine auditors grow discontent.

Why Governance Comes First

Governance answers three questions every auditor and executive will eventually ask:

Who is responsible for information security?
How does the organization decide what risks are acceptable?
How do security decisions support business objectives?

Organizations that can’t answer these questions will drift into one of two paths toward failure.

Path 1: Overly restrictive, deploying controls that frustrate users without meaningfully reducing risk (this is moving beyond friction to inefficiency).

Path 2: Permissive to the point of negligence, accepting risks simply because no one took ownership to decide otherwise.

A governance-driven security program avoids both extreme roads by making risk visible, intentional, and owned – particularly to the proper stakeholders.

The Information Security Policy: Setting the Tone

The Information Security Policy is often dismissed as a formality - it’s a document written once, approved once, and rarely revisited. It’s actually THE SINGLE MOST IMPORTANT policy in the entire ISMS (Information Security Management System).

This policy establishes:
- The organization’s commitment to protecting information
- The objectives of the security program
- The scope of systems, data, and personnel covered
- Management’s authority to enforce security requirements

For ISO 27001, this policy formally defines the scope of the ISMS. For SOC 2, it demonstrates that management has acknowledged responsibility for meeting the Trust Services Criteria.

A note on SOC 2: there are 5 “Trust Services Criteria,” only 1 of which is required (some reviewers can be confused about the flexibility), though more are always a better sign of your security posture to prospects.
More details here: https://cloudsecurityalliance.org/blog/2023/10/05/the-5-soc-2-trust-services-criteria-explained

A strong Information Security Policy avoids technical details. Instead, it speaks in the language of leadership.

NOTE: There’s a difference between policies, procedures, guidelines, and standards. Most of what SMBs, especially unregulated ones, will use are Policies and Procedures. Here’s a good summary: https://www.dummies.com/article/academics-the-arts/study-skills-test-prep/cissp/develop-implement-documented-security-policies-standards-procedures-guidelines-225446/

The main Infosec policy communicates intent, not implementation.

Firewalls, encryption, and monitoring are addressed elsewhere; this policy explains:

why the controls exist, and
who stands behind them.

When auditors review this policy, they’re not looking for perfection (though they will have specific items they have to see, e.g., they’ll demand a Version Table). They’re not looking for specific tools, technologies, or titles. They want to see evidence that leadership understands its role and has set a clear direction for the organization. While it needs to be reviewed at least annually, design it so that it doesn’t need to be changed much, but make it easy to change if needed.

Risk Management: Replace Guesswork with Discipline

Risk management is the connective tissue between the muscles of governance and control implementation. Without it, security decisions are driven by fear, headlines, or vendor influence. With it, decisions become consistent, explainable, and defensible.

A Risk Management or Risk Assessment Policy defines how the organization:
- Identifies risks to information assets
- Analyzes likelihood and impact
- Determines acceptable risk levels
- Selects risk treatment options
- Reviews risks over time

ISO 27001 is explicit in its requirement for a risk-based approach. Controls are not implemented because they appear in some standard somewhere, but because they mitigate identified risks. SOC 2, while less prescriptive, still expects organizations to demonstrate that risks have been identified and addressed through controls.

Risk management does not require mathematical precision (though there are approaches such as FAIR, that rely heavily on mathematical calculations). Auditors expect consistency - assess risks using the same criteria each time, document them in the same way, and review at a defined cadence (often it's expected to be at least annually).

Equally important is ownership. Every significant risk must have a named risk owner - someone accountable for accepting, mitigating, transferring, or avoiding that risk. When risk ownership is absent, risk acceptance becomes accidental instead of intentional.

Roles and Responsibilities: Eliminating the Accountability Gap

A common audit finding across both ISO 27001 and SOC 2 is unclear responsibility. Tasks are performed and decisions are made;, but ownership is vague and authority is implied rather than documented.

A governance policy needs to clearly define:
- Sponsorship from executive leadership for the security program
- Responsibility for maintaining policies
- Authority to approve exceptions and accept risk
- Accountability for system and data ownership

This doesn’t require a large security team, btw. In smaller organizations, individuals often hold multiple roles (a lot of responsibility can be crammed in Security Manager). What matters isn’t separation, but clarity. Auditors want to see that someone has both the authority and responsibility to make security decisions.

Clearly defined roles also reduce friction internally (friction can be good when it puts the brakes on to keep from crashing, but too much and it moves beyond irritating to become detrimental). With documented expectations, security stops being perceived as arbitrary and starts to be predictable and fair.

What Auditors Look For

When auditors assess governance, they’re looking for alignment, not volume. A small, well-integrated set of documents is often more effective than an extensive library of disconnected policies.

Auditors look for:
- Management approval of the Information Security Policy
- Evidence that risk assessments are performed and updated
- Clear assignment of responsibilities
- Consistency between governance documents and operational controls

Perhaps most importantly, auditors look for intent. Controls should exist because risks were identified. Relevant risks should be accepted because leadership understands the implications, not because they want to avoid hassle. Nothing should exist simply because “the framework said so.” Having said that, some regulated industries have rigorous frameworks that already outline what needs to be done. So “the framework said so” is a requisite starting point, and those mandatory controls really do have to be in place – take them seriously, and as needed, go beyond to ensure proper data security. But also, in the spirit of “reasonable security,” don’t take them further than they need to be taken – no sense spending $1 million to protect only $500K of assets. Some examples of rigorous particulars are NIST, HIPAA, HITECH, HITRUST, and PCI-DSS.

Common Pitfalls to Avoid

Organizations can easily undermine governance unintentionally. Common mistakes include:

· Treating the Information Security Policy as a boilerplate document

· Performing risk assessments once and never revisiting them

· Allowing risk acceptance without executive awareness

· Failing to document who owns which decisions

Here’s how to overcome these Pitfalls:

· Make it your own! After having written policies several times in a few organizations, I’ve noticed that it’s difficult whether you create a new policy from scratch, or rewrite existing policies. Lean on your own preference – do you like to create written documents anew? Or do you like to rewrite? The only proper thing to do is to Get. It. Done. But, once you’re done, it’s easy to update.

· Risk assessment needs to be annual – put it in your calendar with ample reminders. Make it an annual meeting with other involved – and let them know if they can’t make it, they need to send someone as a delegate. No exceptions – consider it a baseline or foundation.

· Even in small orgs, email it to all involved or affected (aka, stakeholders). You can even say, “If there are no changes by XYZ date, I’ll take that as acceptance.” That way, you don’t have to follow up with everyone.

· Don’t just write someone’s name down and leave it. They need to be reminded, and that falls to the ISMS lead. Others have many other responsibilities, and it’s easy for them to forget about this and/or let this go. This is where Project Management skills come into play. Take the lead to put it on their calendar, or remind yourself to email them a reminder, about a time to renew and review. Make it part of the org direction, not just a single person’s idea, and that will help get (though not guarantee) agreement on the teamwork.

These gaps don’t necessarily cause immediate problems, but they always surface during audits. Or – regrettably - after a breach, when decisions must be explained under scrutiny. One of the worst things to have to say on the stand is, “We weren’t aware of those risks.”

Governance as a Force Multiplier

Strong governance does more than satisfy auditors. It simplifies every other policy that follows. When objectives are clear and risk tolerance is defined, access control decisions become easier. Incident response becomes more decisive. Vendor risk discussions become more productive.

In many ways, governance is a force multiplier. It allows smaller teams to operate effectively and larger teams to stay aligned. It transforms security from a reactive function into a managed program.

As this series continues, each subsequent policy builds on the foundation established here. Without governance, controls exist in isolation. With governance, they become part of a coherent system.

Afterword about Infosec Policy and Infosec Policies

This primary Infosec Policy can be confused with the Infosec policies. Yes, it’s weird. Some places will ask for your information security policy AND your information security policies. Well, which is it? Here’s an explainer if you’re stuck.

The Information Security Policy is just as described in this article - it’s the overarching source, the foundation, of all-things-infosec.

The infosec policies (plural) are all the other policies involved – access control, backup/restore, physical security, password management, etc.

There’s no way around it: for a good ISMS, you’re going to have numerous policies. A distractor is that policies are often thought of in the way they used to be many years ago – cumbersome, full of irrelevant legalese, written for the erudite and not the common person.

Policies have changed. Yes, they still have to have certain legal wording in them; yes, there have to be several; yes, they have to be updated, documented, and readily available. However, they don’t have to be as long as some may think. To rephrase a saying, this isn’t your grandad’s infosec policy.

SMBs often have a choice in how they work on their entire policy book – an all-in-one (AIO) document, or all separate. If AIO, then it’s just one long document that people have to read and acknowledge. But it’s long and can be tedious to navigate.

If separate, then they’re easier to update, not having to scroll, scroll, scroll. But it can be annoying to have to open 12 separate policies.

But the org gets to decide. There’s no right or wrong, except if you don’t have them.

What’s your next step? If you’re stuck, maybe the resources below will help you along. Do the next thing, and the next thing will follow.

Happy Governing!