Security Engineer

Declare security everyone's job and it usually becomes nobody's. Postponing a check during a week with a feature deadline looks reasonable to anyone, and after that decision repeats twenty times, code nobody has ever reviewed is running in production. No single one of those decisions was wrong, which is what makes the pattern hard to catch.

Pagedeck reached that point at forty-five people. An enterprise customer sent a security questionnaire before signing, and it had 200 items: how access is separated, what encrypts stored data, how many hours until a breach gets reported. Theo spent two days filling it in and half the answers were things nobody knew. Not knowing was half the problem, and having nobody whose job it was to find out was the other half. The questionnaire had simply asked for something the company didn't track.

Grace hired the first security engineer. What changed with a dedicated owner wasn't the number of checks — it was that checks got a place in the schedule. Nobody had to decide weekly whether to postpone them, and that change alone accounted for most of the improvement.

A day splits between what already happened and what hasn't yet. Five things recur.

1. Vulnerability review — both the code written in-house and the outside code pulled in. Automated scans produce the list, and a person picks out what is genuinely dangerous. Most items a scanner returns don't matter in our environment, so the picking is the actual work. A list of 400 findings with no ranking gets read by nobody.
2. Checking for intrusion — access logs and failed login attempts. Looking for patterns unlike the usual, like one account connecting from another country at 3 a.m. Here you judge fast and block the account first when needed. Blocking only after the cause is fully established gives the incident more time to spread, and the order of those two steps is the whole skill.
3. Design review — looking at the permission model before a feature gets built. If the team is building a way to open specific documents to an outside partner, who can reach what, and where that boundary would fail, gets raised before construction. Far cheaper than fixing it after, and the difference is usually weeks against an hour.
4. Access cleanup — periodically sweeping who can reach what. The most common finding in practice isn't an attack; it's a departed employee's account still alive, or a temporary permission still in place six months later. Neither shows up in a scanner, and both show up in a sweep.
5. External responses — answering customer security questionnaires and preparing whatever certification is required. This work sits directly on contract timelines, so it moves to the front of the queue whether or not it was planned.

Splitting the time is the hard part of the role. Stay attached only to what's on fire and the same kind of fire keeps starting. Teams that set a ratio between urgent response and structural work, and record how much time response consumed, fall into this trap less. The record is what makes the imbalance arguable.

It isn't work one person can hold off alone, so most of the time goes to conversation with other roles. Four come up most.

1. Backend developers — the people building the server and data side. Where permission gets decided and which values get stored encrypted are settled together. The most frequent counterpart.
2. DevOps engineers and SREs — the people owning deployment and operational automation, and the people managing service reliability as an engineering problem. Who can log into servers and where secret keys live overlaps their territory.
3. QA engineers — the people verifying quality and building the test system. Put security checks into the test suite and a person no longer has to confirm them by hand each time, which is the only way the checks survive a busy quarter.
4. Sales and legal — customer questionnaires and regulatory demands arrive from here. Sofia passes along the questions she gets before a contract, and items needing confirmation rather than an answer go back to the customer together, which is faster than guessing what was meant. Regulatory questions need supporting documents alongside, so their preparation gets its own window.

The character of these relationships decides the outcome. Once this role starts reading as the person who blocks things, developers find routes around the review. Which makes answering fast the thing that matters. A review that answers within a day gets sought out; one that takes three days gets skipped, and nobody announces that they skipped it.

"Add the security engineer to this design review. The permission boundary changes."

Asking for review before construction.

"A departed employee's account is still live. Let's shorten the access cleanup cycle."

Naming the problem that's more common than attacks.

"Half the items on that questionnaire are things we don't have answers for."

External responses are blocked because no review system exists.

What Pagedeck's security engineer did in the first month wasn't answering the questionnaire — it was building the state in which it could be answered. An access inventory, a list of fields stored unencrypted, and a single page saying who does what when a breach happens.

The same questionnaire arrived again in the second month and took a day. That replaced the two days Theo had spent, and more importantly the unanswerable items dropped to twelve. Those twelve became the next quarter's work list, which is what a questionnaire is actually good for.

The most common belief is that hiring this role solves security. A dedicated owner exists, so it feels that way. But the people writing code are still the developers, and one person can't see everything twenty people produce. What this role does is not block things directly but build the structures that block them. Read as solved, everyone else deletes security from their own job, and from then on one person is the bottleneck for twenty people's output.

The other common belief is that it's a pre-launch checkpoint, a gate you pass after building. But learning the permission model is wrong days before launch costs weeks to fix. Raising the same issue at the design stage takes one conversation. Kept as a checkpoint, the role becomes the person who blocks the schedule, and the person who blocks the schedule stops getting invited to the meeting.