Most COOs treat cybersecurity as something that happens in the IT department, until the day it happens to the whole company. Then a ransomware note appears, a supplier can't ship, payroll can't run, and the person the CEO looks at is you, because it just became an operations problem.

The useful shift is this: cybersecurity is not a control you buy, it is an operational risk you own. Deciding what the business can survive losing for a day, who has authority to pull systems offline, and how fast you can recover, those are operating decisions, and they sit with the COO.

This playbook covers the parts you are accountable for: framing the risk in business terms, applying zero trust, rehearsing incident response, managing vendor exposure, and reporting the few metrics a board should see. You configure nothing. You make sure the right questions get asked and the right money gets spent. For the everyday side, access, leavers, and the ordinary mistakes behind most data loss, see the data security playbook.

Why security is an operations problem, not just an IT one

Your security lead knows the threats. What they usually cannot decide alone is the business trade-off: how much friction to accept at login, or how long finance can run on paper if systems go down. Those are your calls.

A strong COO treats security like any other risk on the register, alongside supply chain and key-person risk. A weak COO treats it as a compliance checkbox IT files once a year. The difference shows under pressure: the checkbox company reads its plan for the first time during the incident, while the register company already rehearsed it. If you are building out enterprise risk generally, security folds into that same discipline, as covered in this COO's guide to risk management.

Most teams reference a framework like the NIST Cybersecurity Framework, organized around five plain functions any operator can read: identify what you have and what could hurt it, protect it, detect problems early, respond when they occur, and recover afterward. You do not implement these. You make sure each one has an owner and a budget.

Frame the risk in business terms, not technical ones

Security teams talk in threats: phishing, credential theft, unpatched systems. That language does not help you prioritize because it does not connect to what the business would lose. Reframe every risk as an operational consequence plus a rough likelihood, then rank by impact.

The point of a risk register is not to list every possible attack. It is to force honest talk about the small number of events that would genuinely hurt, and to put a name against each. A register with the eight things that would stop the business, each owned, is a management tool; a register with 200 unowned items is theater.

The strong version names the operational outcome, sets a recovery expectation, and puts a person against it. That is what lets you talk to the CEO about whether the exposure is acceptable.

Zero trust as an operating principle

Zero trust gets sold as a product. It is really a principle: never assume something is safe because it sits inside your network. Every user, device, and connection proves it belongs, every time. The old perimeter model fails the moment one stolen password gets inside.

In operations, that means a few concrete habits. People get the minimum access they need and no more, the principle of least privilege. Access is reviewed when someone changes role, not only when they leave. Multi-factor authentication is mandatory for everyone, including executives, the most-targeted group precisely because they resist the friction. Systems that do not need to talk to each other stay separate, so a breach in one place does not spread everywhere.

A strong sign: when a salesperson leaves, their access is gone the same day and you can prove it. A weak sign: a departed employee's login still works months later, and nobody can say who can reach the customer database. The value of zero trust is containment. It does not stop every breach, it stops one breach from becoming a company-wide one, often the difference between a bad week and an existential event.

Incident response: rehearse it before you need it

An incident response plan nobody has read is not a plan, it is a liability, because it creates false confidence. The value is in the rehearsal. The phases below repeat every time; your job is to know who leads each one before the pressure hits.

The two phases operators get wrong are the human ones. Containment fails when nobody has authority to take a revenue-generating system offline, so the incident spreads while people ask permission. Grant that authority in advance, in writing. Communication cannot be improvised either: employees, customers, and regulators need clear messages fast, drafted before the crisis, not during it. A prepared crisis communication plan is part of the security plan, and the muscle of leading a live incident is worth building early, as covered in this guide to crisis management for COOs.

Recovery depends on backups you have actually restored from, not backups you assume exist. Test a full restore on a real schedule. Companies routinely discover during a ransomware event that their backups were also encrypted. That test belongs inside your wider business continuity plan, where security is one of several ways operations can be interrupted.

Vendor and third-party risk

Your security is only as strong as the weakest supplier with access to your data or systems. A payroll provider, a cloud tool, a contractor's laptop, each is a door into your business you do not fully control. Many serious breaches enter through a trusted third party, not a direct attack, which makes vendor risk an operations concern.

Strong practice is unglamorous: know every vendor that touches sensitive data, require evidence of their security posture before you sign, write specific obligations into contracts, and give each vendor only the access it needs. Weak practice is a long tail of tools bought by individual teams, no central list, and no idea which suppliers hold customer data. You cannot protect what you have not inventoried, which is why a disciplined vendor management process is one of the highest-leverage security investments a COO can make.

The security metrics worth reporting

Security dashboards drown in numbers that inform no decision. A board does not need the count of blocked spam emails; it needs a small set of measures that show whether the organization is getting more resilient over time.

Focus on a handful that connect to reality: how long it takes to detect and then contain an incident, because speed limits damage; the click rate on simulated phishing tests; the share of systems patched within your target window; and the number of high-privilege accounts, which should trend down as you tighten least privilege. "Zero breaches this quarter" tells you nothing, it may mean you are secure or that you have not noticed the breach yet.

Report the trend, not just the snapshot. A detection time that fell from days to hours over two quarters is a story of improving capability, the narrative that earns the security budget its next increase, especially when tied to the obligations in a compliance management guide.

Build a security culture without running on fear

Technology stops some attacks; people are the difference on the rest. The goal is a workforce that treats security as part of the job, not an obstacle. Fear-based training makes employees hide mistakes, exactly the wrong instinct: a click reported in five minutes is recoverable, one hidden for a week may not be.

A strong culture makes reporting easy and blameless: the person who reports their own mistake is thanked, so problems surface early. Training is short, frequent, and role-specific, not an annual hour clicked through while distracted. And leaders model the behavior visibly, because a policy the executive team quietly exempts itself from is one nobody respects. Progress shows up as incidents reported faster over time and the same mistakes not recurring.

Key takeaways

• Cybersecurity is an operational risk you own, not an IT ticket you delegate. The trade-offs, tolerances, and recovery decisions are yours.
• Frame risks as business consequences with named owners, not technical threats. A short register of what would genuinely hurt beats a long list nobody acts on.
• Zero trust means least privilege, mandatory MFA, and separation, so one breach stays contained instead of spreading company-wide.
• An incident response plan is only worth the rehearsal behind it. Pre-assign the authority to take systems offline and pre-draft crisis messages.
• Vendors are doors into your business. Inventory them, vet them, and limit their access.
• Report trend metrics, detection time, containment time, patch rate, privileged-account count, not a "zero breaches" headline.
• Build a blameless reporting culture. Fast reporting is often the whole difference between a bad week and a disaster.

Frequently asked questions

Should cybersecurity report to the COO or somewhere else? The reporting line matters less than clear ownership of the operational decisions. Security often reports to a CIO or CISO while the COO owns the business-risk trade-offs, continuity, and incident response. What fails is when nobody owns those trade-offs and security sits detached from how operations run. Make the escalation path to you explicit before an incident, not during one. How much should we spend on cybersecurity? Spend should follow your risk register, not a fixed percentage borrowed from another company. Two firms of the same size can face very different exposure depending on what data they hold and what a day of downtime costs. Price the operational impact of your top risks, then fund the controls that reduce those specific exposures first. What is the single most valuable thing a non-technical COO can do? Run a realistic incident rehearsal, often called a tabletop exercise. Gather the people who would actually respond and walk through a plausible scenario out loud: who acts, who can pull systems offline, what you tell customers and when. It costs almost nothing and reliably exposes the gaps: an owner unsure of their role, a backup nobody tested. Is zero trust realistic for a smaller company? Yes, because zero trust is a principle, not an expensive product. The core habits, least privilege, MFA everywhere, and prompt access removal when roles change, cost mostly discipline rather than money. Smaller companies often adopt the fundamentals faster, with fewer legacy systems to untangle. Start with least privilege and universal MFA and you have most of the benefit. How do I know if our security is actually improving? Watch trends in a few operational metrics rather than a single headline number. Detection and containment times that fall over successive quarters show real capability gains. A declining click rate on simulated phishing shows the culture maturing, and a shrinking count of high-privilege accounts shows least privilege taking hold. Improvement is a direction of travel, not a "zero incidents" claim, which usually means you have not detected the breach.