Cybersecurity Governance

Good governance also helps you spend effort where it matters. A small plumbing company may not need a large security department, but it still needs to know who controls the accounting login, how workers report suspicious messages, when backups run, and who contacts the technology provider after a breach. After reading this section, ask yourself: if a security problem started today, could your team explain who decides, what happens first, and how you know the fix worked? If not, governance addresses that gap.

The practical takeaway: governance turns security from scattered tasks into an agreed way of working.

The Governance Purpose Triangle

The Governance Purpose Triangle explains the three areas that governance must connect:

1. People - Assign responsibility and set expectations. Someone owns each important security task, and workers know what safe behavior looks like. This prevents the “I thought someone else handled it” problem. 2. Process - Write repeatable instructions for normal work and emergencies. A process prevents staff from making up different answers under pressure. 3. Technology - Configure and maintain the tools that protect systems and information. Technology supports the rules, but it cannot replace clear ownership or sensible procedures.

The triangle works because each side depends on the others. A rule that requires strong passwords fails if nobody checks account settings. A security tool creates little value if staff ignore its alerts. A trained employee still needs a clear process for reporting a lost phone. Ask yourself: for every important safeguard, can you name the responsible person, describe the action, and point to the technology that supports it?

Start by listing the business activities that could cause harm if they failed. Include payment processing, customer records, email, scheduling, payroll, inventory, and remote access. For each activity, record the information it uses, the people who need access, and the technology involved. Then identify the main failure that governance should prevent. For example, “former workers keep access to email” points to an account-removal process, an owner, and an administrator setting that disables the account.

Next, create a small set of policies. A policy states the rule and its purpose; it does not need to describe every button in a software product. Useful starting policies include account access, device use, data handling, backups, security updates, and incident reporting. Keep each policy short enough for a worker to use. Explain why the rule exists. “Report a lost phone within 30 minutes because the phone may provide access to company email” gives clearer direction than “Protect company devices.”

Then assign an owner and a check for each rule. The owner performs or coordinates the work. The check confirms completion. For example, the office manager may review the list of active payroll users on the first Monday of every month, while the technology provider handles updates. Record the date, result, and correction when needed. This creates evidence that the process operates instead of merely existing on paper.

A useful governance record can fit in a simple table:

| Security need | Owner | Process | Technology check | |---|---|---|---| | Remove departing worker access | Office manager | Notify provider on the worker’s final day | Confirm account disabled | | Protect customer files | Business owner | Limit access to assigned staff | Review shared-folder permissions monthly | | Recover from system failure | Technology provider | Run and test backups | Check the latest backup and restore one file quarterly | | Report suspicious email | All workers | Forward or report it immediately | Review email security alerts |

These entries prevent three common failures: people do not know who acts, workers perform tasks differently, and leaders cannot tell whether a safeguard works. Governance succeeds when the triangle stays connected. The takeaway: every important security rule needs a person, a repeatable action, and a technology check.

A Practical Governance Scenario

A 12-person dental practice stores patient records in a cloud system, uses email for appointment messages, and accepts card payments through a separate provider. The practice discovers that a former receptionist still has an active email account. The owner also learns that backups exist, but nobody has tested whether the practice can restore a file. The Governance Purpose Triangle shows exactly what to fix.

1. List the important services. The practice records patient records, email, card payments, scheduling, payroll, and its internet connection. Expected outcome: the owner sees which systems could interrupt care or expose private information. 2. Name the owners. The practice manager owns staff access; the technology provider owns device updates and backups; the owner approves major security decisions; every worker reports suspicious messages. Expected outcome: each task has one clear person accountable for completion. 3. Write three short rules. The practice creates an access policy, a lost-device policy, and an incident-reporting policy. The access policy requires account removal on the worker’s final day. The lost-device policy requires a report within 30 minutes. The reporting policy requires workers to contact the practice manager immediately instead of replying to a suspicious message. Expected outcome: workers know what to do without waiting for a meeting. 4. Fix the former receptionist’s account. The practice manager disables the account, checks sign-in records for the previous 30 days, changes shared passwords if the worker knew them, and records the completion date. Expected outcome: the old account no longer provides access, and the practice has a record of its review. 5. Review current access. The manager exports the active-user list from the patient-record system and compares it with the current staff list. The manager removes two unnecessary accounts and limits billing access to three workers. Expected outcome: fewer accounts and fewer people can reach sensitive information. 6. Test recovery. The technology provider restores one noncritical file from the latest backup into a separate test location. The provider records the backup date, restore time, and result. Expected outcome: the practice confirms that a backup can produce a usable file rather than assuming it can. 7. Set a repeating schedule. The manager reviews active users monthly, the provider checks updates weekly, and the practice tests one file restore every three months. Expected outcome: security work continues after the initial cleanup.

The numbers make the process usable: 30 minutes for a lost-device report, one monthly access review, weekly update checks, and one quarterly restore test. The practice can measure completion without buying a new system.

Quick checklist

• List the systems that support payments, records, communication, and daily work. - Assign one owner to each security task. - Write short rules for access, devices, data, backups, and incident reporting. - Check that technology settings support each rule. - Record dates, results, and corrections. - Test backups by restoring a real file in a safe location. - Review the list whenever a worker joins, changes duties, or leaves.

If the practice completes these steps, governance has solved specific problems: unknown ownership, excessive access, untested recovery, and inconsistent reporting. The takeaway: start with the systems that would hurt most if they failed, then connect each one to a person, process, and check.

Mistakes That Break Governance

Treating a policy as the finished work

A policy document does not protect anything by itself. If the rule says “review access monthly” but nobody performs or records the review, the business has a promise without control.

Do this: Name the owner, set the date, record the result, and correct failures.

Not this: Store a policy in a folder and assume workers follow it.

The fix works because it turns a statement into a repeatable task with visible evidence.

Giving one person every security responsibility

A business owner may handle passwords, approvals, backups, incident response, and vendor calls because that feels efficient. It creates a single point of failure. If that person becomes unavailable, the business may lose access to essential knowledge and decisions.

Do this: Separate approval, daily administration, and independent checking when possible. For a small business, the owner can approve access, the office manager can maintain the user list, and the technology provider can supply update and backup reports.

Not this: Let one person create an account, approve it, use it, and confirm it was removed.

The fix does not require a large team. It requires another person to review important actions.

Buying technology before defining the problem

A business may purchase antivirus software, cloud storage, or monitoring tools without deciding what the tools must protect or who will respond to alerts. The result can include missed warnings, overlapping products, and false confidence.

Do this: Identify the risk first, assign an owner, define the required action, then select technology that supports it.

Not this: Buy a tool because it has many features and assume those features create governance.

The fix works because technology becomes part of a working system instead of a substitute for one.

Governance prevents confusion before confusion becomes an outage, privacy problem, or costly recovery effort. Use the Governance Purpose Triangle whenever you review a safeguard: who acts, what process guides the action, and what technology confirms or supports it? That question gives your business a practical starting point for every later security decision.

End of chapter one. 39 more chapters in the full book.