How do you turn a customer's 200-line security schedule into a clause-by-clause answer?
answer
- four buckets, one owner per clause
- never a bare yes
- name the evidence artifact
- scope words carry the cost
- one register, reused across customers
basics
~20 sSort every clause into four buckets: already satisfied, partly satisfied, a real gap, or refused. For each satisfied clause name the evidence artifact, cost each gap in engineer-months, and get vague scope agreed in writing before signature.
solid answer
~50 sGo clause by clause and put each into one of four buckets. **Already satisfied** — and the answer is not the word yes, it is the name of the control plus the evidence artifact a customer could be shown. **Partly satisfied** — say what is true today and what the delta is. **A real gap** — cost it in engineer-months plus recurring effort, and give it a date and an owner. **Not applicable or refused** — say so with a reason and, where the concern is real, a counter-offer. Vague clauses get a written interpretation before signature, because scope words carry the money: a clause naming SLSA Build L2 on every artifact costs very differently if 'every artifact' means the packages the customer installs versus every container the company builds. Keep one register, reused across customers, with one named owner per clause.
go deeper
Be ready to say that each clause is answered individually, that a yes must point at something a customer could actually be shown, and that gaps are stated rather than hidden.
Explain the four buckets and the evidence-artifact rule, and show how scope, verification and timing words change the cost of an otherwise identical requirement.
Demonstrate that you would pin the interpretation of broad clauses in writing before signature, assign one owner per clause outside the security team, and cost gaps in both build and run currencies.
Own the register as a product decision: every term you accept becomes the floor for the next twenty deals, so decide deliberately which commitments the company will standardise on and which stay bespoke and priced.
## The exercise A customer security schedule arrives as prose written by someone else's lawyers over someone else's control framework. Your job is to convert it into a set of statements your company can honestly make, plus a costed list of what it would take to make the rest of them true. The work is mechanical if you are disciplined and ruinous if you are not, and interviewers ask about it because somebody in the room has to be the person who does it. ## Four buckets, and the rule about evidence **Bucket 1 — already satisfied.** The temptation is to write 'Yes'. The discipline is to write 'Yes — control X, evidenced by artifact Y'. The evidence artifact is the point: a signed attestation stored with each release, a scan record retained for the support life of the release, a repository setting that cannot be bypassed, an access review export. If nobody can name the artifact, the honest bucket is 2 or 3, not 1. A 'yes' with no evidence behind it is the single most expensive line in the document, because it will be audited later and will fail. **Bucket 2 — partly satisfied.** Very common and perfectly respectable. 'We do this for the three products in scope for this contract; the rest of the portfolio follows in the next two quarters.' Partial answers written honestly build far more trust than blanket yeses, and they set up the renewal conversation. **Bucket 3 — a genuine gap.** Cost it in two currencies: the engineer-months to build it and the recurring cost to keep it running. A control that takes six weeks to build and one day a month forever is a different decision from one that takes six weeks and then runs itself. Attach a date and an owner. If the deal cannot wait for the date, that is a business decision made with real numbers rather than an engineering promise made under pressure. **Bucket 4 — not applicable, or refused.** Some clauses genuinely do not apply to your delivery model — controls written for a hosted SaaS make little sense for software installed on the customer's own hosts, and vice versa. Others apply but buy the customer nothing. Both get an explicit written answer; silently agreeing to a clause you do not intend to implement is the worst outcome available. ## Interpretation before commitment Most of the cost variance in a schedule is not in what the clause asks for, it is in how far it reaches. Watch for: - **Scope words** — 'every artifact', 'all systems', 'any severity', 'at all times'. Each one multiplies the estate the control has to cover. - **Verification words** — 'independently verified', 'third-party attested', 'audited annually'. These convert an engineering control into a recurring procurement line. - **Time words** — response windows, notification windows, retention windows. These convert a control into a staffed duty. - **Named standards** — a clause naming a framework or a level obliges you to read that framework's own text and map each of its requirements to a control you own. Never answer from the acronym; the level names are not self-explanatory and the customer's understanding of them may not match the specification's. Agree the reading in writing before signature. 'Every artifact means the deb and rpm packages delivered to Customer under this agreement' is one sentence that can be worth several engineer-years. ## Run it once, reuse it forever The first schedule is expensive. The second should not be. Keep a single internal register: control, current state, evidence artifact, owner, and the standard wording you use to describe it. Each new customer schedule is then a mapping exercise against the register rather than a fresh archaeology project, and — importantly — every commitment you make is visible in one place, so you can see when one customer's terms have quietly become the company's baseline. ## Ownership One named owner per clause, and it is usually not the security team. The team that runs the release pipeline owns the pipeline clauses; the team that runs the estate owns the patching clauses. Security owns the register and the arbitration, not the delivery of every control in it. ## What good looks like in the interview A strong answer is boring and specific: buckets, evidence artifacts, costed gaps, written interpretations, one owner per line, one reusable register. A weak answer is either 'we'd review the requirements and comply' or a heroic promise that the team can do all of it by the go-live date.
- What makes a clause that looks cheap turn out to be expensive?Reach and recurrence. Scope words like 'every artifact' or 'any severity' multiply the estate a control must cover; verification words like 'independently attested' add a recurring procurement line; time windows like four-hour notification convert a control into a staffed duty. The engineering work is often small next to what those three words do to it.
- The clause names a standard and a level you have never implemented. What do you do before answering?Read the specification's own text and map each of its stated requirements to a control you own, one line at a time. Answering from the acronym is how companies commit to things they cannot evidence, and the customer's understanding of the level may not match what the specification actually requires.
- Sales has already signed a schedule with a go-live date. How does the exercise change?The buckets are the same; the output is different. You still map every clause and name the evidence, but the gaps become a prioritised remediation plan with dates, and the ones that cannot land by go-live get escalated as a disclosed deviation with a target date rather than quietly ignored. Deciding what to tell the customer is the first move, not the last.
saying these in an interview costs you the question
- Answers yes without naming the evidence that proves it
- Skips the written interpretation of vague scope words
- Costs the build but not the recurring operating effort
- Treats every clause as security's own delivery duty
- Starts a fresh archaeology project for each new customer