Security Policy

At a small company, security rules live in people's heads for a long time. Who can grant administrator access, whether customer data may be downloaded to a personal laptop, who has to approve a new tool before company data goes into it — all of it depends on who asks and who happens to answer.

Then something like this happens. An engineer leaves, returns the laptop, and has their accounts closed. Months later a production database key turns up in that person's personal cloud storage. Trace the problem back and nobody broke a rule. There was no rule saying work files stay out of personal storage, and nothing defined what gets checked when someone leaves.

Without written rules, every decision is made in the moment, and decisions made in the moment lean toward whatever unblocks the work. "Can you open this up for me, just for today" does not get refused when there is nothing to refuse it with.

A security policy makes those decisions in advance and fixes them in writing. When the situation arrives, the team follows something already written instead of debating who decides. Enterprise security reviews and certification audits both ask for the document, which can make the paperwork look like the point, but the real value is having a standard in place at the moment somebody is in a hurry.

Seven groups cover it: accounts, permissions, devices, data handling, tool adoption, incident reporting, and exceptions.

1. Accounts and authentication — how passwords are created and stored, where two-factor authentication is mandatory, and whether shared accounts are allowed at all. Shared logins are usually prohibited, because they make it impossible to tell who did what after an incident, and because nobody rotates a password that four people rely on.
2. Permissions — who approves administrator access, what the default level is, and when temporary grants expire. Without an expiry written in, the same stale entries keep surfacing at every access review.
3. Devices — disk encryption on laptops, screen locking when someone steps away, how far work data may be opened on personal devices, and how quickly a lost device must be reported and to whom. A number here matters more than the instruction: within one hour, to the security owner, is a rule somebody can follow at an airport.
4. Data handling — data gets classified, and each class gets a rule about where it may live and how it may be shared. Four levels are common: public, internal only, customer data, and data that identifies a person in a sensitive way.
5. Tool adoption — who signs off before company data goes into a new external service. Without this rule, one team expenses a survey tool and customer emails start accumulating somewhere nobody is tracking.
6. Incident reporting — what counts as an incident, and how many minutes someone who notices one has before telling whom. An incident response plan is what picks that report up and runs with it.
7. Exceptions — the route for getting approval when a rule genuinely cannot be followed. A policy without this section does not get followed; it gets bypassed.

Whoever owns security writes it, and at a company with nobody in that role the founder writes it with an engineer. The starting point is not the ideal rule but what the company actually does today. Write rules two steps stricter than reality and everyone finds a way around them.

Length is part of the rule set. Under about fifty people, three or four pages is the right size. A forty-page document does not get read to the end, and an unread rule is the same as no rule.

Four audiences read it.

1. Staff — once in their first week, and after that only when an ambiguous situation comes up and they go looking. Keeping the document findable is the other half of keeping it short.
2. Engineers — the group that translates rules into code and configuration. A stated scope for mandatory two-factor authentication is, in practice, the specification for the account settings.
3. Enterprise customers — pre-contract security reviews ask for the document directly, and gaps in it turn into questions in the meeting.
4. Auditors — certification work checks whether the document and the actual operation match. A company that only wrote the document well is caught here.

Updates come every six to twelve months, and whenever the toolset or the organization changes. Revisions get logged, and what changed goes into security training so it reaches people rather than sitting in a file.

"What does the policy say about this? Downloading customer data to a personal laptop."

Looking for the answer in the document rather than treating it as personal discretion.

"Temporary access auto-expires after two weeks per the policy, so I'll set the date and grant it."

The rule carries a deadline, and the deadline gets enforced as written.

"Write the policy that strictly and nobody will follow it. Let's bring it down to something people can actually do."

A proposal about the distance between the document and reality.

Pagedeck wrote its policy after receiving the security checklist from its first enterprise customer. The first thing Grace did while drafting was not deciding rules but asking Theo how things currently worked — how many people held administrator access, and who could open screens containing customer data.

The count came back at 12 of 45 people with administrator rights. Writing "administrator access requires founder approval" into the policy meant revoking access for nine of those twelve. Grace chose to shrink the access rather than soften the sentence, spent two weeks doing that first, and only then finalized the wording.

The most common assumption is that stricter writing produces more safety. A strong sentence in the document feels like protection. But a rule that cannot be followed is not followed; it is routed around. Prohibit all file sharing and people start sending files through personal messaging apps, and from that point the company has no visibility into what went where. That is a worse position than having no rule, because the company believes it banned the thing and therefore stops looking. The workable version names an approved way to share files and prohibits the rest.

The second misreading is that having the document means having a policy. Since audits and customer reviews ask for the file, producing it feels like completing the task. When the document and the operation diverge, the document becomes the company's own written standard and the clearest evidence of the gap. A policy works as a policy once inspection and drills are attached to it. The permission rules on paper have to be compared against the actual permission list every quarter for the document to stay in touch with reality.