Governance is one of the areas, I think, where you have an inflection point and suddenly it hits you: “good governance is helpful”.

Quite what that epiphany moment is will vary. When it does, you might want to remember about this post, and think, “Adam had some alright thoughts on the topic”.

My take is that all areas of a business need governance, not just a select few; there’s a reason for years, there’s been finance committees, risk committees, and remuneration (pay) committees. Increasingly, we see these adapting to include product, data, privacy, ethics, cyber, risk.

A good committee structure is healthy, especially where voting members are educated on the topics and hold the officers to account, ensuring that the function is helping solve business issues, and has clear accountability and escalation routes. I think they’re also great opportunities to sponsor colleagues’ work — giving them recognition.

We’ve all been in meetings that could be emails.

For governance committees, I have an expectation that people will review their papers before the meeting, but also be aware of which items are:

  • for information
  • follow-ups from previous requests
  • needing a decision (and which options)
  • areas for conversation/deep discussion
  • really rather important

I like minutes to be sequential, so they can be referred to; for companies in scope of ECCTA, you may find you need to retain some of these documents for a decade, so being able to unambiguously refer to decisions may be helpful (my style is <entity>/<committee>/YY-MM/<agenda-number>; setting the details as the list prefix in g-docs).

I’ve experimented with tracking items in jira/monday, and found it to be too much admin, especially when meetings aren’t driven by the tools. I’ve yet to see an affordable ‘minuted meeting’ tool that doesn’t suck.

Subscribe now

Agenda

As suggested, prior to a meeting, it will be effective to circulate an agenda. Ideally this will be a week or so before, although that is very aspirational, especially where you’re a very lean time/solo/individual contributor.

If you’re aspiring to be, or already certified, under ISO 27001, you will find that some of the agenda is required (these refer to clauses of the standard, not the optional annexe controls):

9.3 ​Management review

9.3.1 General
Top management shall review the organization’s information security management system at planned intervals to ensure its continuing suitability, adequacy and effectiveness.

9.3.2 Management Review Inputs
The management review shall include consideration of:
a) the status of actions from previous management reviews;
b) changes in external and internal issues that are relevant to the information security management system;
c) changes in needs and expectations of interested parties that are relevant to the information security management system;
d) feedback on the information security performance, including trends in:
    1) nonconformities and corrective actions;
    2) monitoring and measurement results;
    3) audit results;
    4) fulfilment of information security objectives
e) feedback from interested parties;
f) results of risk assessment and status of risk treatment plan;
g) opportunities for continual improvement.

9.3.3 Management Review Inputs
The results of the management review shall include decisions related to continual improvement opportunities and any needs for changes to the information security management system.
Documented information shall be available as evidence of the results of management reviews.

This essentially means, demonstrate attendance, continual improvements, self-reflection, and acting on these; the other aspects — the defined agenda items — are a mix of awareness/context, good governance, or inputs to lead discussions on the areas deemed critical by the ISO.

How much of those items are just “noted” will depend on your business, the maturity of the organization, and the appetite; but note these are clauses, rather than Annexe A controls, so there’s not much wiggle-room.

Some auditors I’ve encountered are more rigid about this than others, especially given it’s in the clauses, not the annexes. Evidence of discussion of these can be sampled by an auditor. It’s apparently a common weakness to be poor in this area, but one that should strengthen over time (and remember, you should have adequate resourcing for the ISMS):

Cl. 7.1 …provide the resources needed for the establishment, implementation, maintenance and continual improvement of the information security management system

I don’t think it’s especially helpful to cover all of these, and to be honest, have spent very little time on these; although it’s been raised as a finding to look at them (but not deemed a major non-conformance). If you can, you should cover them. You may need some help in gathering these.

InfoSec Metrics

if it’s not measured, it can’t be improved.

Your KPIs/KRIs should be things you can measure, and report on (and not take ages to extract).

I think the traditional metrics like `percentage of people up to date in training` is not so helpful; same with phishing campaign outcomes. I’m interested in the trends, so corrective actions can be discussed, and agreed on.

The opposites can also be interesting, as Carpenter & Roer note — measure the people who never report emails as spam — the messaging isn’t working — rather than those where the training has been effective.

Agenda packs

I’ve experimented with a mixture of styles for the agenda, but it seems to be more effective to (ab)use slide-decks, although I try not to jam too much into a slide, favouring linking back to docs, spreadsheets, systems for those curious in finding out more (make sure to share other documents with attendees so if they do have 10 mins to review the deck, they can).

In an ideal world, it would be more data-driven, and through a series of dashboards in the MI/BI [Management/Business Information] platform. As said, I’ve yet to find a tool that doesn’t suck. Some MCPs could really help make this work, for each business.

I start with the essentials; get them over and done with, then able to focus on the important parts that work for you; the areas that need decisions, rather than a nice chat. Here you might need to be a little pragmatic in the order; depending on availability of key people, and/or voting members or quoracy.

Terms of Reference

ChatGPT will help you produce a reasonable set of terms of reference, so long as your prompt involves telling it what standards/requirements you want it to know about and include. It will probably struggle with who the members should be, or what quorum looks like. I’ve found current versions of ChatGPT, Gemini, and Claude to be lacking in knowledge of the Corporate Governance Code (which I mostly like).

As ever, it’s better to keep this concise. Clarify what the committee’s functions are, what authority they have (and from whom; ideally it’s a subcommittee of group board), and the ability to command resources.

Pro-tip: You might find it useful to allow the CISO to approve, pending committee approval/ratification, minor changes to policies and/or the promulgation of new policies, especially if your committee only meets once a quarter.

My top hint on Terms of Reference has been to set the cadence of meetings to be at least quarterly, but allowing for more frequent meetings, subject to availability (excluding seasonal shutdowns), with a view that it’ll meet 7-9 times a year.

As hinted, because your standards require top management’s involvement, you should ensure

  1. the committee has delegated authority from the top management
  2. attendance from top management
  3. robust, independent scrutiny, including from the non-executive directors.

Making it a sub-committee of risk (or exec), however tempting, decreases its influence — and is complementary to, not subordinate. You may find it helpful to do this from the start, before an auditor doesn’t certify you, or you fall short of the legislative/regulatory requirements for a top-level committee.

Agenda (part 2)

Here’s something like what I’ve done before — as mentioned above, it’s not perfect, so don’t copy/paste it! (but a picture can be helpful and breaks up the wall of text a bit).

Make sure the agenda works for you. It can always be iterated on (especially if it’s not set in the Terms of Reference, but at the Chair’s discretion) If you’re going to use slides, have a template that sets out the purpose of the item:

is it for:

  • information
  • noting
  • discussing
  • agreeing to.

You might find it useful to have a consistent structure:

  • problem (customer A wants…)
  • relevance (will 20% of ARR stop if nothing is done?)
  • data (customers, risks, ease, etc)
  • options (1… 2… 3… 4…)
  • recommendation (2 because it’s the most practical now, but 3 is more expensive but more future proof/scalable for other customers)
  • annexe (costs, timelines, people needed etc, risk register entries, competitor analysis, third-party reports etc)

Attendees

Big committees don’t add much value, especially where there are multiple voting members and politics. Leave those aside, and focus of smaller but effectiveness.

  • CISO (Chair)
  • Secretary (non-voting)
  • CTO
  • Chief Risk Officer
  • 2 x Non-Exec Directors (including the SID, where appointed)
  • 1 x Exec Director

A few other blogs suggest having representatives from all departments. Whilst security is cross-functional, you will know best if everyone who heads a department will get value from a meeting, if they’ll contribute effectively, have competence in the area, or will just sit there, hopefully muted, catching up on emails/slack. My preference is to take reports, and feedback outcomes/actions to people directly.

Having the CISO on Exec can be helpful — smaller discussions can happen there / the impact of security on planning can be demonstrated that way. This implies that there is a strategic, functional executive committee, where everyone has the same information at the same time and operates effectively, not just a roundtable of updates (that naturally, could have been an collaborative document).

Other people may be involved as attendees — standing or ad-hoc, e.g. the Incident Manager may be a report to the committee, but only pulled in for the “incidents” section, departing after their presentations/Q&A.

Closed-sessions

There may be some areas of discussion that need to be kept confidential; e.g. if discussing active insider-threats, possible HR actions, or even potential referral to police/prosecutorial authorities.

You should ensure (a) you can do this, (b) there’s a means to remove these sections from recordings that are shared internally.

Established security industry procedures, like the Traffic-Light Protocol may be helpful for marking sections of the agenda.

extrā omnēs.

Further thoughts…

Thinking beyond the requirements, I’m now thinking that to help this committee work effectively, a few others should feed up to it:

  • HR, IT, Security — for covering joiners, movers, leavers; training & development, human-centric approaches
  • Data & AI — data governance; AI governance etc.
  • Security champions — feedback from the security champions / embedding security in all teams
  • IT & Security — corporate IT posture
  • Platform & Security — dev & infrastructure security arrangements
  • Privacy — to complement the privacy forum (q.v. Art 38 and Art 39)
  • Vendor Management — oversight of vendor management (possibly shared with finance committee?)
  • Operations — incidents, Service Level breaches, disaster recovery/business continuity/resilience exercises etc.

Thanks for reading ☙ Security Says "Yes" ❧! This post is public so feel free to share it.

Subscribe now