Audit

Writing a rule down and living by it are two different jobs. A company can produce a security policy document in an afternoon; whether anyone followed that document for the past six months is not something the document can show. For a long time, though, reading documents was the only way an outsider could assess a company's security.

So enterprise deals kept stalling in the same place. Sofia would say Pagedeck managed security carefully, and the buyer's security contact would ask how they were supposed to verify that. What Pagedeck could hand over was a document in which it praised itself, and the other side had no way to test it.

An audit fills that gap. Instead of the document describing what a company intends to do, a qualified third party samples the records showing what it actually did. The only real change is moving the basis of the claim from assertion to evidence, and that shift is what lets someone outside the company judge what happens inside it.

An audit starts by drawing a line around what will be examined and ends with a list of findings. Five steps.

1. Set the scope. Nobody audits every system a company owns at once, so you decide up front which services and which servers are in. Pagedeck includes the document editing service and the production servers behind it, and leaves the internal test servers out.
2. Map the framework's controls onto how you actually operate. A control is one management measure aimed at one risk, written as a single sentence — lock a departing employee's account on their last day, for instance. One framework carries around a hundred of them, and for each you write down what your company does.
3. Collect evidence. Evidence is the record showing the control was really followed. Not a sentence saying the account was locked, but the screen showing the date it was locked and who did it.
4. The auditor samples and compares. If twelve people left during the year, they won't review all twelve — they'll pull four or five at random and check the account revocation records. One mismatch in the sample means the control counts as not operating.
5. Findings get written up and fixed. The output is not a pass mark but a list, control by control, of what fell short. Minor items come with a deadline; serious ones hold up the certificate until they're resolved.

Step 3 eats the most time. Companies that fall behind usually aren't missing rules — they're missing traces of having followed them. A log the system writes on its own carries more weight than a table someone typed up by hand.

Three distinct roles show up. The external auditor makes the call, an internal owner drives the preparation, and the people doing the work produce evidence control by control. The auditor judges but does not fix; telling you how to fix something would mean designing the thing they're about to assess. At Pagedeck, Grace picks which certificate to pursue, Theo owns the access and deployment records, and Sofia delivers the result to customers. At 45 people the owner role is almost always someone's second job.

Timing splits in two. An internal audit — the company running the check on itself — goes in two or three months before the external one. Running it early surfaces the controls with no evidence behind them, and a control that fails during the external review stays in the report as a finding even after you fix it.

It also doesn't end. ISO 27001 requires a surveillance audit every year and a full recertification every few years. SOC 2 has a type that examines whether controls held up across six to twelve months, so records have to run unbroken through that window, and ISMS-P, the Korean scheme, brings a follow-up review the year after you pass.

"Scope for this audit is the editing service and the production servers behind it. Test servers are out."

A line has been drawn, and anything outside it won't appear on the certificate.

"We have the control for account revocation but no evidence. Let's clear it in the internal audit."

The rule was followed but left no trace, so the record needs to exist before the external review sees it.

"The three findings from last year are closed — remediation reports are attached."

Items marked deficient in the previous review were fixed, and this review is being shown proof of it.

Pagedeck's first audit came when a customer with several hundred employees asked for a security certificate alongside the contract. Grace picked a framework and preparation began, and once the control list was open it turned out almost nothing was actually missing. The problem was that all of it lived in Theo's head.

So most of the preparation was not writing new rules but changing existing work so it left records. Theo moved permission changes from something done by hand to a request-and-approval flow with a history, and started writing up the results of a twice-yearly permission review. Four of the five items the auditor sampled came straight out of that history; the fifth landed in a period with no history and became a finding.

The most common mistake is treating an audit as something you pass once. The result arrives as a single certificate, so it feels like a qualification. In practice most frameworks re-examine you every year, and the types with an observation window feed the records made after the review into the next one. Left alone, the same scramble repeats twelve months later: permission review records stop the day after the audit closes, and the whole company piles back in two months before the next one.

The second is treating an audit as one security person's job. There's a named owner, so it looks like the owner handles it. But evidence only exists where the work happens. Deployment approvals sit with engineering; vendor contracts sit with the executive and sales side. An owner working alone ends up emailing ten people the same request two weeks out, and records assembled in a hurry have dates that don't line up under sampling.