Security Governance

Security was treated as a purchasing problem for a long time. Buy a firewall, install antivirus, attach a box that collects access logs, and the job looked done. Budgets were built the same way. Asked how much the company spent on security, you added up licence costs, and when something went wrong the next step was a more expensive product.

The incidents that actually happened, though, kept landing where no device could catch them. Someone in a hurry pastes a production database credential into a team channel and never deletes it. A contractor gets temporary access and keeps it long after the contract ends. A fake email in the chief executive's name arrives and the finance lead opens the attachment. None of these is a piece of equipment failing. They happen because the work people do, and the routine that checks that work, were never defined.

Pagedeck learned this from an enterprise security questionnaire. One item on the sheet Sofia brought back asked when a departing employee's accounts get locked, and Theo stopped halfway through writing the answer because the company had no defined answer. Pulling the account list that afternoon turned up a designer who had left three months earlier with a live account, and a contractor whose repository access had outlasted the contract by two months. Nobody was unsure how to lock an account. What was missing was a named person to do it and a scheduled day to confirm it had been done.

Security governance is the name for filling that gap. What gets protected, who checks it and on what day, who fixes it when the check fails: all of that is decided in advance, and then the whole arrangement gets reviewed on a schedule to see whether it still matches reality. What separates a real incident from a near miss is rarely the quality of the safe; it is how many keys were cut and how many of those are in the hands of people who left. Operations, not technology, is the character of this work. The way in is not picking a product but writing out what is currently undecided. Of the seventeen blanks Pagedeck found on one questionnaire, twelve were blank because no rule existed, not because the rule was wrong. That ratio is typical of a company this size. The engineering habits are usually sound and the gap is that nobody has written down which habit is the rule, who confirms it, and how often.

The terms under this name fall into five branches. Counting what has to be protected is inventory. Writing down how to protect it is policy. Running those rules on a schedule is procedure. Taking over once something gets through anyway is response. And deciding which direction the other four face is principle.

Inventory counts the targets. The asset inventory is one table holding the systems and data that need protecting. Not only servers and databases but the outside tools the company pays for, the data sitting inside those tools, and the laptops people work on. Each row records who owns it and what kind of data it holds. This table has to exist before anything else works, because a system missing from it is also missing from the permission review and missing from the list of places anyone checks after an incident. The contractor's repository access survived at Pagedeck for exactly that reason: the repository was on no table anywhere. What gets left out most often is the tools individuals signed up for on their own — one team paying by company card for a survey product that has accumulated several thousand customer email addresses. Those only surface when someone reads through the card statement. Keeping the table current is its own small routine: a row goes in when a tool is added and comes out when the account is closed, and once a quarter somebody checks the table against the actual bill.

Policy fixes the method in sentences. A security policy is the document holding rules like how passwords are made, who approves administrator access, and how far company data may travel onto personal devices. Writing it is not the hard part; writing rules that can be kept is. Set the bar two steps above what the company actually does and everyone finds a way around it, and from then on the document describes something other than reality.

Procedure runs the written rules against what is happening. Three terms here.

1. Access review — pulling the list of who can reach what on a regular cycle and taking back the permissions nobody needs any more. Once a quarter is a common rhythm. Tying it to a date rather than to a person is the point, because granting access leaves a trace in the form of a request while access becoming unnecessary announces itself to no one. Requests to open something up just for now rarely end when now does.
2. Security training — teaching the people in the company the practices they are expected to follow. The most common shape is one long annual session, which is also the least effective one. Telling a new hire in their first week how far they may look into customer data at this company prevents more incidents than an hour of general advice delivered to everyone at once.
3. Phishing drill — sending convincing fake email inside the company and counting who clicks. The goal is the rate and how to lower it, not the names. Share the list of people who clicked and nobody reports anything in the next round, and once reports dry up there is no one to raise a hand when a real message arrives.

Response takes over after something gets through. An incident response plan is the document setting out who does what in which order once an incident starts. It names the person who decides an event counts as an incident, the person with authority to take the service down, and the person who notifies customers and regulators, and it puts a number of hours on how long notification may take. The hours are written as a number because the law often sets a notification deadline. Starting an argument about who decides while an incident is live spends that deadline on the argument.

Principle sets the direction the other four move in. Zero trust means nothing is trusted merely for being inside the corporate network: every access rechecks who is asking and whether that permission is still valid right now. The older model drew one perimeter and treated everything inside it as safe. With people working outside the office and company data spread across several outside services, the inside of that perimeter stopped existing, so the test moved from location to identity. The other four branches get reread on top of this. Asset inventories group by data rather than by network, and access reviews attach to individual people rather than to departments.

The five branches close a loop. The inventory counts the targets, the policy attaches rules to each one, reviews and training and drills carry those rules to people, the response plan takes the day they fail anyway, and what the incident teaches goes back into the policy and the inventory. Showing the outside world that this loop is turning is the job of security compliance.

"That permission should have been revoked in last quarter's review. It was never on the list to begin with."

The bigger problem is not the stale permission but the system missing from the asset inventory.

"There's no rule covering this. Let's decide now and fold it into the next revision."

Make the call in the moment, but put the call back into the document afterwards.

"Click rate on this drill was 18 percent and the report rate didn't move."

Plenty of people took the bait and almost nobody flagged it, so the training needs to change direction.

After the departing-employee incident, Pagedeck settled three things. Locking accounts on someone's last day became part of the joining and leaving checklist. Every quarter Grace pulls the full permission list and walks it with Theo. And connecting a new outside tool without adding a row to the asset inventory means the payment does not get approved. None of the three came from buying anything. Each one attached a date and a named person to work the company was already doing.

The human side took longest. On the first phishing drill, eleven of forty-five people clicked the link and exactly one reported it. Grace shared the rates and never the names. On the second drill, clicks dropped to six and reports rose to nine. What Theo said looking at those numbers was that the good news was the reports, not the clicks. Someone always clicks on the real one, and what happens next depends on whether anyone says so.

The most common mistake is expecting a purchase to produce a program. Security vendors mostly pitch a single screen where everything is managed, so the assumption is easy to form. What a tool delivers, though, stops at showing the current state. Products that pull a permission list exist; deciding which permissions are no longer needed and taking them back is human work, and with no named person and no date the list just piles up in the same shape every quarter. Leave the mistake in place and spending rises while the blanks on the customer questionnaire stay blank, because items asking when the review ran, who signed off, and what was found and fixed cannot be answered with a product name.

Believing that more rules mean more safety is the other one. A thick document looks like preparation, and it looks especially attractive with an assessment coming. But a rule that cannot be kept does not simply go unkept; it trains people to route around it. Require two approvals for every production data query and approvals start getting skipped during urgent outages, and after that happens a few times the clause may as well not exist. The document and the daily reality then split apart, nobody can say which one is the actual rule, and there is no way left to produce a record of compliance. The test when writing is not how strict the rule is but whether anyone can verify it was followed. Instead of loosening a rule you can also log the exceptions: recording that an approval was skipped and why, then reviewing those cases together later, beats leaving a clause in the document that nobody honours. The exceptions then become the agenda for the next revision, since a rule broken the same way every month is describing a process that needs changing rather than people who need reminding.