Control

The question an enterprise customer asks before signing is usually one line: is your security any good? It's an awkward question to answer. Saying yes rests on nothing, and listing what you do leaves the other side with no way to judge whether it's enough. "The servers are encrypted" and "we clean up accounts when people leave" are different kinds of information arriving in the same breath.

Conversations like that used to hold contracts up for months. A security lead at the customer sends over a questionnaire with twenty items, and the receiving side chases down a different person for each answer. The next customer sends much the same questionnaire and the whole round starts over.

Controls solve this by breaking the subject apart. Instead of one large word, you get dozens of sentences that resolve to yes or no. Accounts are locked on an employee's last working day. Access to the production database requires approval from two people. Framed that way the answer changes shape: rather than a claim that things are fine, there's a count of how many items out of a hundred are covered and how, and the customer can go straight to the handful they care about.

One risk gets one measure, written as a sentence, and that sentence is checked on a set rhythm. A single control usually carries five things.

1. The risk it blocks. Start with the thing that would be a problem if it happened, such as a departed employee still being able to read customer data.
2. The measure actually taken. Written as an action: all system accounts are locked on the last working day. Phrasing like "we aim to" doesn't work, because nobody can check it.
3. The frequency. Every time an event occurs, or once a quarter. Without a rhythm there's no way to say when it was missed.
4. The owner. One named person watches whether this holds. Put a team name here and nobody watches it.
5. The record it leaves. Where the proof that the measure happened ends up, and in what form.

Controls fall into three groups by what they do: prevent something from happening, detect it when it does, and respond once detected. Granting access only to people who need it prevents. Keeping access logs so unusual entries surface detects. A written procedure for who gets notified within how many hours responds. All three have to exist, because prevention alone leaves no way to know when it failed, and detection without a response plan means finding out at two in the morning with nobody clear on who to call.

How a control gets verified splits in two as well. Either a person opens a list once a quarter, or the system blocks and records automatically. The second is better. A quarterly human check leaves three months uncovered between passes, while a system that refuses access without approval has no moment where the rule was broken. In an audit, a system-generated record also counts for far more than a table someone typed up.

Work happens in these units when preparing for certification, when attaching a new tool or feature, and when answering a customer's security questionnaire.

First, it's the base unit of certification work. Schemes like SOC 2, ISO 27001 and Korea's ISMS-P hand over a framework of several dozen to a hundred-odd items, and the company writes down how it handles each one. Even across schemes, more than half the questions overlap. That's why a second certification moves much faster: build a mapping table once and the same material goes out in a different format.

Second, it's a checklist when new systems go in. Rather than reasoning about security from scratch for every feature, you check which existing controls the change touches. Bringing in an outside vendor's tool pulls in a vendor assessment as well, since customer data flows on to that company and the commitments you made have to hold there too.

Third, answering customer questionnaires. With the controls written down, a twenty-item questionnaire becomes an hour or two of work instead of several days, because most of the questions are restatements of controls you already hold. The ones that don't map to anything are worth keeping — a question several customers ask that nothing on your list answers is usually the next control to write.

"This one is set up as a quarterly review. Let's switch it to something the system enforces."

Replace a periodic human check with a continuous block so there's no uncovered gap.

"That feature needs a new control. Nothing on the current list covers it."

The measures defined today don't address the risk this change introduces.

"The control exists but there's no evidence. An auditor treats that as nonexistent."

Defining it and even following it doesn't count if no record survives to show it.

When Pagedeck took on its first enterprise customer, building this list fell to Theo. It started with a question rather than a document. Counting who could reach the production database gave eleven people, four of whom hadn't opened it in over six months. The sentence about reviewing access quarterly and reclaiming unused accounts got written on the spot, and the record of reclaiming those four became the first piece of evidence.

What Grace checks when she reads the list isn't the number of entries. It's whether each one names a single owner, and whether there's a trace of it actually running last quarter. An item with a blank owner or no record exists on the list and nowhere else.

The most common belief is that writing the document creates the control. Certification work starts with paperwork, and finishing the policy documents feels like finishing the job. But what an auditor looks at is the trace of the sentence being acted on. Write that access is reviewed quarterly, then produce no record for the last four quarters, and you're worse off than having no control at all — you documented a commitment and didn't keep it, which stays in the report as a finding.

The other misreading is that more controls mean more safety. A long list looks thorough, and it's tempting to adopt every item in the framework. But a control you can't keep reduces no risk while adding something else to maintain. Companies that fall behind usually aren't short of controls; they wrote down more than they could run and arrive at the audit with half of them idle. Picking the items that match your actual risks and running those properly works better.