Building an ISO 27001 Project Team: Roles and Governance

Marcus Webb found out his ISO 27001 project was dead the same week he found out it had never really been alive.

Marcus was the IT infrastructure manager at Anchor Bay Logistics, a 210-person freight-brokerage technology company outside Charlotte. In February, the VP of Sales had closed a deal with a national retail chain worth roughly $2.4 million a year — contingent on Anchor Bay holding ISO 27001 certification within twelve months. The CEO forwarded Marcus the contract clause, added the line "can you own this?", and moved on to the next fire. There was no charter, no budget line, no steering committee, and no conversation about what "owning this" meant in terms of hours, authority, or headcount.

Marcus did what capable people do when handed an ambiguous mandate: he started working. He bought a GRC tool. He hired a consultant for a gap assessment. He drafted a risk register during nights and weekends, because his actual job — keeping the network running — didn't pause to make room for a management system. Eleven months and roughly $180,000 later (consultant fees, tooling, and the fully-loaded cost of Marcus's diverted time), Anchor Bay brought in an external readiness reviewer ahead of a planned Stage 1 audit. The reviewer's findings were blunt: the risk register listed forty-one risks, but eighteen had no named owner. Three Annex A controls were marked "implemented" in the Statement of Applicability with no evidence and no one who could produce any, because no one had ever been told the control was theirs. The information security policy Marcus had drafted had never been formally approved by anyone with the authority to approve it — it existed as a Word document with a version number and no signature. Worst of all, when the reviewer asked "who is accountable for this ISMS to the board?", the honest answer was: no one. The CEO had delegated the deliverable but never accepted the accountability that Clause 5.1 actually requires of top management, and nobody above Marcus's pay grade had ever convened to make a single risk-acceptance decision.

The retail contract's compliance deadline moved up by four months when the customer's own auditors flagged the relationship as high-risk. Anchor Bay's board finally named an executive sponsor — the COO — chartered a four-person steering committee, and reassigned three control owners from IT, HR, and Facilities in a single afternoon. Certification still happened, but ten months later than the original commitment, at a total program cost about 35% higher than a comparable engagement I've run with governance in place from day one. Nothing in that outcome was a control-implementation problem. Annex A never failed Anchor Bay. Its team structure did.

I've spent more than fifteen years building and rescuing ISO 27001 programs across more than 200 organizations, from eight-person SaaS startups to multinational manufacturers, and Marcus's story is not an outlier — it's close to the median. The technical work of information security management — writing policies, hardening endpoints, closing vulnerabilities — is rarely what kills a certification timeline. What kills it is ambiguity about who is accountable, who has authority to decide, and who shows up to a room every month to make sure decisions actually get made. This article is about fixing that ambiguity before it costs you a Marcus Webb story of your own.

Who This Is For

This article is for anyone who has been asked to stand up — or fix — the human structure behind an ISO 27001 implementation: a newly designated ISMS manager building a team from nothing, an executive sponsor who wants to understand what they're actually accountable for, a compliance lead inheriting a program with unclear ownership, or a founder at a small company trying to figure out how few people can realistically do this well. You'll walk away with a concrete set of roles mapped to what the standard actually requires, a worked RACI you can adapt directly, a governance and decision-rights model with a defensible meeting cadence, and a clear-eyed view of what changes as your organization scales from twenty employees to two thousand.

Why the Team Makes or Breaks Your ISO 27001 Project

Across the certification engagements I've been part of or reviewed as an external assessor, the technical gap between a passing and failing Stage 2 audit is almost always small — a handful of controls under-evidenced, a metric not yet tracked long enough. The organizational gap is where programs actually die: risk owners who were never told they were risk owners, control owners who find out during the audit that a control was "theirs," steering committees that exist on an org chart but haven't met in five months, and internal auditors reviewing controls they personally designed. In my own tracking of stalled or restarted engagements, roughly two-thirds trace back to one root cause: nobody with real authority was accountable for the whole system, only for pieces of it. A project team with clear roles and a governance rhythm doesn't just move faster — it produces the kind of evidence trail (meeting minutes, decision logs, escalation records) that auditors read as proof the management system is actually operating, not just documented.

What ISO 27001 Actually Requires: Clause 5.1, 5.3, and Annex A 5.2, 5.4

Before you design a team, it's worth being precise about what the standard obligates you to do — because it's less prescriptive than most first-time implementers assume, and the gaps people invent to fill that ambiguity are usually where trouble starts.

Clause 5.1 (Leadership and commitment) requires top management to demonstrate leadership by ensuring the information security policy and objectives are established and compatible with the organization's strategic direction, ensuring the ISMS is integrated into business processes, ensuring resources are available, communicating the importance of effective information security management, and — critically — directing and supporting people to contribute to the ISMS's effectiveness. Clause 5.1 does not name a job title. It names a set of behaviors top management must exhibit, personally, on an ongoing basis. Delegating the paperwork to a manager does not satisfy Clause 5.1 if top management never resources, reviews, or visibly backs the program.

Clause 5.3 (Organization, roles, responsibilities and authorities) is the clause that most directly governs the subject of this article. It requires top management to assign and communicate responsibilities and authorities for roles relevant to information security, including — explicitly — a role responsible for ensuring the ISMS conforms to ISO 27001 and a role responsible for reporting on ISMS performance to top management. That's it. The standard does not require a "Chief Information Security Officer," an "ISMS Manager," or any other specific title. It requires that someone, clearly designated and resourced, holds each necessary responsibility, and that this assignment is documented and communicated — not assumed.

Annex A control 5.2 (Information security roles and responsibilities) operationalizes this at the control level: information security roles and responsibilities must be defined and allocated according to the organization's needs, covering asset owners, risk owners, and anyone with operational security duties. Annex A control 5.4 (Management responsibilities) requires management at all levels to require personnel to apply information security in accordance with established policy and procedures — in other words, management's job isn't just to have policies, it's to actively require and reinforce compliance with them through normal management channels, not just through a compliance team's nagging.

The practical implication: you have real latitude in naming roles, combining roles, and sizing your structure to your organization — a fifteen-person company does not need a five-person steering committee — but you have zero latitude on the underlying requirement that authority and accountability be explicit, assigned to named individuals (not "the IT department"), documented, and communicated. Auditors test this directly. A common Stage 2 finding is an org chart that shows a role but an interview that reveals the person in that role didn't know they held it, or didn't know what authority came with it. For a deeper walkthrough of these specific clause and control requirements, see our guide to ISO 27001 Clause 5 leadership and management commitment and the companion piece on roles and responsibilities under controls 5.2 through 5.4.

The Core Roles at a Glance

Every ISO 27001 program — regardless of size — needs these functions filled. What changes by organization size is whether each function is a dedicated person, a part-time responsibility bolted onto an existing job, or a role shared across several people. The table below is the reference structure I bring into every kickoff.

Two patterns are worth flagging immediately. First, one person can legitimately hold more than one of these roles in a small organization (an IT manager can be both ISMS manager and a control owner), but no single person should ever combine internal auditor with any role that has operational ownership of what's being audited — that's not a style preference, it's a direct requirement of Clause 9.2's independence expectation, which we'll cover in detail later. Second, "Steering Committee" is listed as a role, but it's really a governance body composed of several of the other roles meeting on a cadence — we'll separate the org chart from the governance chart shortly, because conflating the two is one of the most common design mistakes I see.

"The single question I ask in every kickoff meeting now is: 'If the ISMS manager needs $40,000 for a new logging tool next quarter, who says yes?' If the room can't answer in under ten seconds, the governance model doesn't exist yet — no matter what the org chart says." — Renata Silva, Director of GRC, Ashford Meridian Insurance

The Executive Sponsor: Accountability Starts at the Top

The executive sponsor is the single most under-specified role in ISO 27001 programs I've reviewed, largely because Clause 5.1 describes behaviors ("top management shall demonstrate leadership and commitment") rather than a job title, and organizations read that ambiguity as permission to skip the role rather than as a requirement to fill it deliberately. In practice, the sponsor is the person who makes the ISMS survive contact with competing priorities.

A real executive sponsor does four things no one else in the structure can do. First, they secure and defend the budget — tooling, consulting, training hours, and the ISMS manager's time allocation — against the normal organizational pressure to reallocate resources to revenue-generating work. Second, they resolve cross-functional conflict that the ISMS manager has no authority to resolve: when the engineering VP refuses to prioritize a vulnerability remediation ticket, or when HR balks at a background-screening control, the sponsor is who makes the call stick. Third, they accept risk above a defined threshold — every risk acceptance criteria document should specify a dollar or severity threshold above which the ISMS manager cannot sign off alone, and the sponsor is who signs above that line. Fourth, and most visibly to auditors, they represent the ISMS to the actual board or ownership structure during management review, satisfying the intent of Clause 5.1 that leadership commitment be demonstrated, not delegated into invisibility.

The sponsor does not need deep technical security knowledge, and in my experience the best sponsors are rarely security specialists — they're operators (a COO, a CFO, a VP of Engineering) who understand how to move budget and resolve conflict inside their specific organization. What they cannot be is absent. The single highest-correlation predictor I've seen for a stalled or over-budget certification timeline is a sponsor who attended the kickoff and then never again showed up to a governance meeting until the Stage 1 audit was already scheduled.

Recruiting the right sponsor in the first place is its own skill, particularly in organizations where information security has historically been seen as a cost center rather than a business enabler — a topic detailed enough that we cover the pitch and the internal politics separately in a forthcoming guide on securing management buy-in for ISO 27001 programs.

The ISMS Manager: The Person Who Runs the Program

If the sponsor is accountable for the ISMS existing and mattering, the ISMS manager is accountable for it functioning day to day. This is the role most people picture when they think "who runs our ISO 27001 project," and it's the one job in this article that genuinely benefits from a dedicated, named individual rather than a shared committee function — even in a small organization, someone needs to hold the whole picture in their head.

The ISMS manager's job, in practice, breaks into five buckets: maintaining the scope statement and Statement of Applicability as the single source of truth for what's in and out; running the risk assessment and treatment cycle, chasing risk owners for decisions rather than making those decisions unilaterally; coordinating the mandatory document set (policies, procedures, records) and keeping version control sane; scheduling and preparing for internal and external audits, including gathering evidence from control owners; and — the part that gets skipped most often — preparing the management review inputs that Clause 9.3 requires top management to actually review. A good ISMS manager spends less time writing policy prose and more time chasing people: reminding a control owner that an overdue action item is blocking the SoA, following up on a risk treatment plan that stalled, or making sure the steering committee agenda reflects real decisions rather than status theater.

Sizing this role honestly matters. In organizations under roughly 100 employees, the ISMS manager is almost always a part-time responsibility layered onto an existing IT, compliance, or operations role — typically 20-40% of a full-time role during build-out, dropping to 10-15% in steady-state maintenance. Past a few hundred employees, or in regulated industries with multiple overlapping frameworks, this becomes a full-time role, sometimes with a small team underneath it. Underestimating the time this role actually requires — treating it as a five-hours-a-week add-on for a person already at capacity — is the single most common resourcing mistake I see, and it's the one that put Marcus Webb, from our opening story, eleven months into a stalled project before anyone noticed.

ISMS Manager vs. CISO: Why ISO 27001 Doesn't Require Either Title

A question I get in nearly every kickoff call: "Do we need to hire a CISO before we can pursue certification?" The answer is no — ISO 27001 does not require a Chief Information Security Officer, an ISMS Manager, or any specific title to exist anywhere in your org chart. What it requires, per Clause 5.3, is that the responsibilities normally associated with those titles are assigned to a named person with adequate authority and resources, however you choose to label the position.

That said, the two roles are not identical in scope, and conflating them causes real confusion in larger organizations that have both.

In smaller and mid-size organizations, one person routinely wears both hats, and that's entirely compliant with the standard as long as the authority and resourcing described in Clause 5.3 are genuinely present — not just implied by the title on a business card. In larger organizations where a CISO already exists, the cleanest structure I've implemented has the CISO serve as executive sponsor or a senior steering committee member, with a dedicated ISMS manager reporting into that function to run the certification program itself, freeing the CISO to focus on the broader security mission rather than document version control.

Control Owners: Who Actually Makes the Control Work

A control owner is the person accountable for a specific Annex A control functioning in practice — not the person who wrote the policy about it, and not the ISMS manager who tracks whether it's done. This distinction matters because the single most common evidence gap I find in Stage 2 audits and in internal audits I've conducted is a control marked "implemented" in the Statement of Applicability with no individual who can speak to how it actually works day to day.

Control ownership should map to whoever has genuine operational authority over the underlying process or system, which usually means it's distributed across functions rather than concentrated in IT or security.

The practical test for whether control ownership has been assigned correctly is simple: can that person, with no advance notice, walk an auditor through how the control operates, produce the relevant evidence from their own systems, and explain what happens when the control fails? If the honest answer routes back to "you'd have to ask the ISMS manager," ownership hasn't actually been assigned — it's been assumed.

"My test for a control owner is whether they can explain the control in their own words, in under two minutes, without looking at the policy document. If they have to read it to me, they don't own it — they're just the name attached to it." — Marcus Webb, IT Infrastructure Manager, Anchor Bay Logistics

Process Owners vs. Control Owners: A Practical Distinction

Where control owners map cleanly to a single Annex A control or small cluster, process owners are accountable for an end-to-end business process that typically touches several controls at once and often crosses functional boundaries. Conflating the two — or worse, having neither clearly assigned — is why incident response and access management are two of the most frequently cited weak spots in internal audit findings I review.

A concrete example: access provisioning touches control 5.16 (identity management), 5.18 (access rights), 8.2 (privileged access), and 8.5 (secure authentication). Each of those can have a named control owner. But unless someone owns the process of provisioning, reviewing, and de-provisioning access end to end — typically an IT operations manager — you get exactly the gap auditors love to find: a terminated employee whose account was disabled per the HR control but whose privileged database access, owned by a different control owner, was never touched because no one owned the handoff between the two.

Risk Owners: Accountability for Acceptable Risk

Risk owners are distinct from control owners and from the ISMS manager, and the distinction is one ISO 27001 is explicit about even though it doesn't hand you a template for how to assign it. A risk owner is the person with the authority and accountability to decide how a specific risk is treated — accept it, mitigate it, transfer it, or in rare cases avoid it entirely — and that authority has to sit with someone close enough to the business impact to make an informed call, not with the ISMS manager by default.

In practice, this means risk ownership is usually distributed to business and functional leaders rather than centralized in a security function. The risk "customer PII exposed via a misconfigured cloud storage bucket" might be owned by the VP of Engineering, who can weigh the cost of additional controls against delivery timelines and has the authority to reallocate engineering time to fix it. The risk "key supplier suffers a ransomware event that disrupts our supply chain" might be owned by the Head of Procurement or Operations, who understands the contractual and business continuity trade-offs involved.

A pattern I actively correct in nearly every risk register review: someone (often the ISMS manager, sometimes a security analyst) has been listed as the owner for dozens of risks spanning HR, engineering, physical security, and finance simply because they built the register. That's a documentation convenience, not real accountability — and auditors increasingly probe this by asking the named "owner" directly why they accepted a given risk, in an interview the ISMS manager isn't present for. If the answer is "I didn't know I owned that," it's treated as a finding. For a full treatment of how to assign and defend risk ownership, see our dedicated guide on risk owners and accountability under ISO 27001.

"I tell every risk owner the same thing in their first ten minutes on the register: your name next to a risk means you could be asked, in an audit interview, to justify why you accepted it — not why the security team accepted it on your behalf." — Devon Okafor, Head of Risk, Calderwood Manufacturing Group

Internal Auditors: Independence Is Non-Negotiable

Clause 9.2 requires internal audits of the ISMS at planned intervals, and it builds in a structural requirement that trips up more organizations than any control implementation gap: auditors must be independent and impartial, meaning no one can audit their own work or a process they operationally own. This directly connects to Annex A control 5.3 (segregation of duties), which requires conflicting duties and areas of responsibility to be separated to reduce opportunities for unauthorized or unintentional modification or misuse.

For a small organization, this creates a real staffing puzzle. If your ISMS manager is also your only IT manager, they cannot conduct the internal audit of IT-related controls — someone else has to, even if that means a peer manager from a different department auditing an area outside their usual expertise, a rotation arrangement with a sister company or parent organization, or an outsourced internal audit provider. What you cannot do is have the control owner sign off on their own control's internal audit, or have the ISMS manager audit the very documentation set they personally maintain, and call it conformant.

The internal auditor role also needs enough authority to be meaningful: access to any in-scope area, the ability to raise a nonconformity without needing sign-off from the person being audited, and a direct reporting line to the steering committee or top management for findings — not through the ISMS manager alone, since in many structures the ISMS manager's own work is squarely in scope. Our detailed walkthrough of internal audit planning, execution, and reporting covers scheduling, sampling, and nonconformity classification in depth. If you're building the interview approach for your first internal audit cycle, our Internal Audit Interview Question Script gives auditors a structured set of questions by control area so first-time internal auditors aren't improvising in the room.

The Steering Committee: Where Governance Lives

If the roles above are the "who," the steering committee is the "where decisions actually happen." I've seen more ISO 27001 programs stall from a missing or non-functional steering committee than from any single missing control, because without this body, every cross-functional trade-off — budget, scope, risk acceptance, resourcing conflicts — has nowhere to go except an ad hoc hallway conversation that no one remembers three weeks later and no auditor can verify happened at all.

A functional steering committee is typically four to seven people: the executive sponsor (chair or co-chair), the ISMS manager (secretary and primary presenter), a senior IT or security representative, an HR representative, a legal or compliance representative, and — in organizations with distinct business units — a rotating business unit lead whose area is under active scope or risk discussion. Internal auditors should never sit on the steering committee in a decision-making capacity; they may be invited to present findings, but their independence is compromised if they're also voting on the remediation approach for their own findings.

The committee's job, concretely, is to: approve and periodically re-approve the ISMS scope statement; review and approve the risk register and treatment plan at a summary level (not risk-by-risk micromanagement — that's the risk owners' job); approve budget requests above the ISMS manager's discretionary authority; resolve escalations that individual control or process owners couldn't settle themselves; and prepare the formal inputs that feed Clause 9.3 management review. In smaller organizations, the steering committee and the management review body are often literally the same group meeting under two different agenda headers — which is fine, as long as both sets of required inputs and outputs are actually covered and documented.

Decision Rights: Who Can Say Yes, and Who Must Say Yes

A charter that lists roles without decision rights is decoration. The single most useful artifact I build with a new steering committee is a one-page decision-rights matrix that answers, in advance, "who can approve this without a meeting, and what has to wait for the committee?"

Publishing this matrix — even in a one-page form attached to the project charter — does two things simultaneously. It speeds up day-to-day work because most decisions never need to wait for a monthly meeting, and it gives auditors exactly the kind of evidence Clause 5.3 is looking for: a documented, communicated allocation of authority, not an assumed one.

Escalation Paths: When Something Needs to Move Up

Escalation is where governance models most often go quiet in practice, even when they're well-documented on paper. The pattern I correct constantly: a control owner discovers a blocking issue — a budget shortfall, a conflicting business priority, a control that can't realistically be implemented as scoped — and instead of escalating it formally, they quietly let the deadline slip, hoping it resolves itself or that no one notices before the audit.

A working escalation path needs three things: a named first point of contact (usually the ISMS manager, not the sponsor directly — sponsors should not be a first-line triage function), a defined maximum dwell time before an unresolved issue must move up automatically (I recommend no more than two weeks for anything blocking a committed milestone), and a standing agenda item at every steering committee meeting literally titled "open escalations," so that unresolved items have nowhere to hide between meetings. The mechanism matters less than the discipline: I've seen escalation paths work equally well as a dedicated Slack channel with a defined SLA and as a formal ticket queue in a GRC tool, as long as someone is accountable for making sure nothing sits untouched.

Reporting to Top Management: Feeding Clause 9.3 Management Review

Clause 9.3 requires top management to review the ISMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness — and it specifies required inputs: status of actions from previous reviews, changes in external and internal issues relevant to the ISMS, feedback on performance including nonconformities and corrective actions, audit results, achievement of information security objectives, feedback from interested parties, risk assessment results and risk treatment plan status, and opportunities for continual improvement.

The steering committee's governance cadence should be structured so that most of these inputs are already assembled as a byproduct of routine governance meetings, rather than requiring a scramble the week before a scheduled management review. In the model I typically build, the ISMS manager maintains a running management review input log throughout the year — updated after every steering committee meeting — so that the formal, top-management-attended management review (often once or twice a year) is a synthesis and decision session rather than a data-gathering exercise. This also gives you a defensible answer when an auditor asks how the organization ensures continual improvement is actually being driven from the top, rather than generated retroactively to satisfy a checklist.

Meeting Cadence: Sizing Governance to Your Organization

Cadence is where I see the most over-engineering in larger organizations and the most under-governance in smaller ones. Neither extreme serves the program.

The guiding principle: cadence should be tight enough that no issue can go two full cycles without visibility, and loose enough that the meetings themselves don't become the bottleneck they're meant to prevent. In year one of certification, I generally recommend organizations of every size run their steering committee tighter than the steady-state pace shown above — the muscle memory built in the first 90 days before Stage 1 pays for itself for years afterward.

The Project Team and Governance Structure

The diagram below separates the reporting/org-chart relationships from the governance flow — a distinction that matters because a control owner's manager and their ISMS accountability line are often two different people, and conflating the two in a single diagram is a common source of confusion during kickoff.

Note the dotted independence lines running from the internal auditor to the ISMS manager, control owners, and process owners — those represent the segregation-of-duties boundary that Clause 9.2 and Annex A control 5.3 require, not a reporting relationship. The internal auditor reports findings directly to the steering committee, never through the ISMS manager's own reporting chain, precisely because the ISMS manager's work is frequently within audit scope.

"The moment we drew the org chart and the governance chart as two separate diagrams, half the confusion in our kickoff meetings disappeared. People had been arguing about reporting lines when they actually meant accountability lines." — Tomas Bergqvist, VP of Operations, Fennwick Industrial Systems

A Worked RACI Example

RACI charts fail when they're built as an abstract exercise disconnected from the actual roles above. Below is a worked example covering a representative slice of ISMS activities — enough to adapt directly to your own program. R = Responsible (does the work), A = Accountable (owns the outcome, one per row), C = Consulted (input sought before action), I = Informed (told after the fact).

A few things this table makes visible that prose alone tends to obscure. The steering committee holds "A" (accountable) on the truly governance-level decisions — scope, risk acceptance above threshold, policy approval, budget, corrective action closure for major nonconformities — while the ISMS manager holds "R" (responsible) on nearly everything, reflecting that they do the operational work but rarely own the final call alone. The internal auditor appears almost nowhere except their own lane, which is exactly the point: independence means minimal entanglement in the activities they might later be asked to audit.

This is a deliberately compact example; a full production RACI typically runs to 40-60 rows once you break out every control cluster and process individually. If you're building yours from scratch, we go into the row-by-row construction methodology — including how to handle shared accountability and multi-framework overlap — in our dedicated guide on building a security RACI.

Team Structures for Small Organizations

For an organization under roughly 100 employees — the range where I most often see ISO 27001 pursued to win a specific enterprise contract or satisfy a specific regulatory pressure — the honest, defensible structure is lean, and trying to build a five-committee governance apparatus here does more harm than good.

The single adjustment I make most often for small organizations: resist the urge to have the ISMS manager also serve as the sole risk owner for everything. Even at twenty employees, pushing risk ownership out to whoever actually runs the affected function — even if that's the same three or four people wearing multiple hats — produces materially better risk-acceptance decisions than centralizing it with whoever built the spreadsheet.

Team Structures for Mid-Size Organizations

Between roughly 100 and 1,000 employees, the structure typically needs to formalize what small organizations handle informally, mostly because the number of control owners and the volume of risk decisions outgrow what a 3-4 person steering committee can track in a monthly hour-long meeting.

At this scale, the distinction between control owners and process owners (covered earlier) starts to matter operationally rather than academically — enough controls and enough people are involved that end-to-end processes need a single accountable owner distinct from whoever owns the individual pieces.

Team Structures for Large and Complex Organizations

Above roughly 1,000 employees, or in any organization managing multiple overlapping compliance frameworks (ISO 27001 alongside SOC 2, HIPAA, or industry-specific regulation), governance typically needs to formalize further into a layered structure with regional or business-unit sub-committees feeding a central governance body.

Large organizations also benefit most from formal charter documents for each governance body, defined term limits or rotation for steering committee business-unit representatives, and a documented framework-mapping exercise so that overlapping obligations (an ISO 27001 control that also satisfies a SOC 2 trust services criterion, for instance) aren't governed by two disconnected teams duplicating the same evidence-gathering effort. Organizations pursuing both frameworks simultaneously often find that a single governance body, with a shared control-mapping exercise, cuts total audit preparation effort meaningfully compared with running two entirely separate compliance teams in parallel.

Resourcing the Team: Part-Time vs. Dedicated Roles

The most common resourcing question I get isn't "who should fill this role" but "how much of their time will this actually take" — and the honest answer is that most first-time implementers underestimate it by roughly half, particularly for the ISMS manager role.

These figures are illustrative estimates drawn from the range of engagements I've run, not a universal formula — a highly regulated organization with a complex supply chain will run higher across every row, while a single-product SaaS company with a clean tech stack can often run toward the low end. The point of building the estimate explicitly, though, isn't precision — it's making the true cost visible before you assign the ISMS manager role to someone already at 100% capacity on their existing job and hoping the math works out. It rarely does, and when it doesn't, the ISMS manager role is what quietly stops progressing, exactly as it did for Marcus Webb in this article's opening story.

What a Part-Time ISMS Manager Actually Costs You

The instinct to keep the ISMS manager role part-time and folded into an existing position is usually financially reasonable for smaller organizations — a dedicated full-time hire rarely makes sense under 100 employees. But it's worth being explicit about the trade-off you're accepting, because "part-time" is often used to mean "whenever there's spare capacity," which is a very different commitment.

All figures above are illustrative planning ranges based on the engagements I've priced and reviewed, not published salary survey data, and will vary significantly by region, industry, and the maturity of your existing IT and HR functions. The comparison exists to make one point concrete: the "informal, as-time-allows" model looks free and is actually the most expensive option in the table once you account for the rework, consultant fees, and delayed contracts that follow a stalled program — as Anchor Bay Logistics discovered at a cost of roughly $63,000 in avoidable rework and delay penalties beyond their original budget.

Documenting Role Assignments: What Auditors Actually Want to See

A team structure that exists only as tribal knowledge — "everyone knows Sarah handles vendor risk" — fails an audit even when Sarah genuinely does handle vendor risk well. Clause 5.3 requires that roles, responsibilities, and authorities are not just assigned but communicated, and auditors interpret "communicated" as documented and discoverable, not merely understood informally by long-tenured staff.

The documentation doesn't need to be elaborate. What I typically build with a client is a single role-assignment register — often a tab in the same spreadsheet or GRC tool that houses the risk register and SoA — listing every named role, the individual currently holding it, the date they were assigned, the authority level associated with the role, and a cross-reference to where that authority is defined (the charter, the decision-rights matrix, or an email of appointment from the sponsor). This single artifact answers the two questions auditors ask most often in role-related interviews: "how do you know this person is authorized to do this?" and "what happens when this person leaves?"

The "backup / succession" field deserves particular attention because it's the field most programs skip and the one recertification auditors probe hardest, precisely because role turnover between the initial certification and the first recertification cycle is close to universal — the Ashford Meridian Freight Partners case study earlier in this article is a version of this exact gap, just concentrated in the internal auditor role specifically.

"The role register isn't bureaucracy for its own sake — it's the artifact that turns 'I think Sarah handles that' into 'here's the date Sarah was assigned, by whom, with what authority, and who backs her up if she's out.' That sentence is worth more to an auditor than any policy document in the room." — Sofia Reyes, ISMS Program Manager, Solvane Health Systems

Common Mistakes That Sink ISO 27001 Project Teams

After reviewing team structures across more than 200 organizations, the failure patterns repeat with remarkable consistency.

The last row deserves emphasis: the team you build to get certified is not automatically the team that should maintain the ISMS afterward. I recommend a formal team-structure review at every management review cycle, explicitly checking whether every named role still has a real, current, capable person behind it.

"We reorganized our steering committee membership the same week we renewed our cyber insurance, purely by coincidence — and the insurer's questionnaire asked almost the identical governance questions our certification auditor had asked six months earlier. Good governance turned out to be reusable across every relationship that cared about our risk posture." — Priya Chandran, Compliance Director, Fennwick Industrial Systems

Keeping the Team Current: Onboarding, Turnover, and Competence

A team structure designed once during certification build-out and never revisited is a slow-motion version of the same failure that hits organizations that never designed one at all — it just takes a year or two longer to surface, usually at a surveillance audit or recertification cycle rather than the original Stage 2 audit. Annex A control 5.2 and the broader Clause 7 competence requirements both point toward the same discipline: role assignments need active maintenance, not a one-time announcement.

Three moments in the lifecycle of a team member deserve a defined process rather than an improvised one. When someone is newly assigned a role — control owner, risk owner, steering committee member — they need a documented handoff: what the role covers, what authority comes with it, where the relevant evidence lives, and who to escalate to. When someone already in a role changes function or seniority, their existing assignments need an explicit review rather than a silent continuation, particularly for risk ownership, where authority should track the person's actual current standing in the organization, not their standing when the risk was first assigned. And when someone leaves a role — whether they leave the company entirely or simply move to a different team — the register described earlier needs an immediate update, with the backup identified in that register stepping in formally rather than the role quietly going unfilled until the next audit notices.

That last row matters more than it looks: general security awareness training, the kind most organizations already run for all staff under control 6.3, is not a substitute for role-specific competence when someone inherits control ownership, risk ownership, or a steering committee seat. A new HR director inheriting control ownership for screening and background checks needs to understand what evidence the control requires and how audits test it — not just the general awareness content every employee receives. Skipping this step is how a well-designed team structure quietly degrades into the tribal-knowledge problem this article warns against, one personnel change at a time.

Case Study: The Sponsor Who Showed Up Too Late

A 340-employee healthcare technology vendor I'll call Solvane Health Systems began its ISO 27001 program with an enthusiastic ISMS manager, a reasonable budget, and a CEO who signed the kickoff charter and then, by his own later admission, didn't think about the program again for seven months. The ISMS manager built a strong risk register and made real technical progress on Annex A controls, but every decision requiring cross-departmental authority — reallocating an engineering sprint to close a vulnerability finding, requiring background checks for a category of contractor HR had exempted, approving budget for a SIEM tool — sat unresolved because no one below the CEO had the standing to force the decision, and the CEO wasn't in the room to make it himself.

By month eight, with a Stage 1 audit six weeks out, the ISMS manager escalated directly to the board, bypassing the CEO's normal chain of command out of sheer necessity. The board convened an emergency session, formally designated the COO as executive sponsor with explicit budget authority, and gave her a standing 30-minute slot in the weekly leadership meeting for ISMS escalations. Within three weeks, four previously stalled decisions were resolved. Solvane passed Stage 1 on schedule and Stage 2 four months later, but the emergency escalation and compressed remediation sprint added an estimated $85,000 in accelerated contractor costs that a properly resourced sponsor role would have avoided entirely. The lesson the CEO took away, in his own words during the closing management review: "I thought signing the charter was the commitment. It turns out showing up was the commitment."

Case Study: The Two-Person Team That Outperformed a Task Force

A 45-employee fintech startup, Corvid Payments Technology, took the opposite approach from most of its funding-stage peers: rather than assembling a large cross-functional task force, the founder-CEO personally served as executive sponsor and designated the head of engineering as ISMS manager at a genuine, protected 30% time allocation — formally removing an equivalent portion of his other duties, not just adding the role on top.

Control ownership was distributed to exactly four people: the head of engineering (technical controls), the office manager (physical and asset controls), an HR consultant retained part-time (people controls), and the CEO himself (supplier and legal controls, given the company's small vendor footprint). The "steering committee" was, functionally, the CEO and the ISMS manager meeting for 45 minutes every two weeks, with the other two control owners joining monthly. Internal audit was outsourced to a boutique firm for a two-day annual engagement. Corvid achieved certification in nine months at roughly 60% of the cost benchmark I typically see for companies its size, primarily because there was zero ambiguity about who decided what, and escalations resolved within days rather than weeks. The structure worked specifically because it matched the organization's actual scale — the same four-person model would have failed badly at ten times the headcount, but at 45 employees, more governance apparatus would have been friction, not rigor.

Case Study: When the Internal Auditor Wasn't Independent

A regional logistics company, Ashford Meridian Freight Partners (roughly 260 employees), passed its Stage 2 certification audit cleanly, which made the finding eighteen months later, during its first recertification cycle, particularly costly. The company's IT security manager had been serving as both the control owner for the majority of technical Annex A controls and the internal auditor conducting the annual internal audit — a structure no one had flagged internally because the same person had genuinely done thorough, well-documented audit work.

The recertification auditor identified the independence violation immediately: Clause 9.2 requires auditors to be free of bias and conflict of interest, and a person cannot credibly audit controls they personally implemented and maintain. The finding was classified as a major nonconformity, not because any control was actually failing, but because the entire internal audit program's evidentiary value was undermined — every prior internal audit finding (or lack of findings) was now suspect. Ashford Meridian had to commission an emergency independent internal audit, covering the full scope, within 90 days to close the nonconformity and avoid losing certification. The eventual fix was structurally simple — rotating internal audit duties to a peer manager in finance with basic auditor training, supplemented by an external audit every third year — but the 90-day scramble cost more in consulting fees than three years of a properly independent internal audit program would have cost from the start.

Building the Team Before You Need It

The organizations that build their ISO 27001 team structure well tend to treat it as a permanent operating capability rather than a project that ends at the certificate. That distinction shows up concretely in how they staff for the implementation roadmap from gap analysis to certification: they name the sponsor and ISMS manager before the gap analysis even starts, not after it identifies the gaps, because the people who will own closing those gaps should be part of deciding how big they are. It's a small sequencing change with an outsized effect on how much ownership people feel over the findings versus how much they feel like a compliance burden being handed down from outside.

If your organization hasn't yet formalized the underlying concepts this article assumes — the difference between the ISMS as a management system and the individual controls within it, or the vocabulary auditors and consultants will use in every conversation about roles — our overview of ISMS core concepts and our ISO 27001 terminology and glossary are useful grounding before you assign a single role.

The Strategic Payoff: Governance as a Competitive Asset

It's tempting to treat everything in this article as overhead — the meetings, the charters, the decision-rights matrices — standing between your organization and the certificate a customer contract actually demands. I'd push back on that framing based on what I've watched happen on the other side of well-run programs. A steering committee that meets on a real cadence, a RACI that assigns genuine accountability, and a sponsor who shows up isn't compliance theater; it's the same governance muscle that makes an organization faster at closing enterprise security questionnaires, calmer during an actual incident because escalation paths already exist and are rehearsed, and more credible to acquirers or investors running due diligence, who read a functioning governance structure as a proxy for operational maturity well beyond information security specifically.

The team you build for ISO 27001 also tends to become the team your organization reaches for the next time a customer asks about SOC 2 compliance, the next time a regulator asks about data protection accountability, or the next time the board asks who's watching third-party risk. Getting the roles and governance right once, deliberately, pays a dividend every time a new compliance or risk conversation starts from an org chart that already has clear owners instead of a scramble to figure out who's responsible for what.

If you're at the stage of assembling this team from scratch, start with the sponsor conversation before anything else — no amount of control-owner enthusiasm compensates for an accountability gap at the top. Our Complete ISO 27001 Implementation Guide eBook walks through team formation alongside the full certification timeline, and our Information Security Policy Template and ISO 27001 Mandatory Documents Checklist give your newly named ISMS manager a running start on the documentation the steering committee will need to approve in its first sessions. When you're within a few months of your Stage 1 audit, our Certification Readiness Checklist is built specifically to pressure-test whether your roles, evidence, and governance rhythm are actually ready — not just documented.

Building the right team isn't the price of admission for ISO 27001 certification. It's the actual deliverable. The certificate is just the byproduct of a governance structure that, done well, keeps paying for itself long after the audit ends.