A written standard, and the product checked against it.
The security week is a fixed module, not a phase that varies by project. It produces three things: a written security specification, a hardening checklist worked through item by item, and a report you keep. Everything below is what those three contain and what you can re-run yourself.
- The report and the specification are yours. Not a summary of ours — the document your next engineer works from.
- Every mark carries a date, and a check nobody has attempted yet is marked not yet run — in the report, in writing, rather than left blank.
- It is not sold as an extra. The security week is one of the engagement's versions, priced exactly as every other version is.
The security week
The rule underneath every engagement shape is the same: the full module runs once the thing that will carry real users exists, and before real users' own data is in it. Earlier is a check against a product that has not been built; later is a check whose findings arrive after the exposure.
| How the work arrived | When the security week runs |
|---|---|
| A rebuild | After the core, its adapters, multi-tenancy and the real integrations, and before the run-it week — the boundaries exist by then and are not yet carrying real users. |
| Ongoing product work | The version before the one that first puts a real user's own data into the product, and again at each four-weekly architecture review, because the boundaries are still moving. |
| Landing zone + desk | After the six are built, before the desk takes in the first app. The zone's access separation is the boundary every app that moves in inherits. |
| The slow part, fast | In the same version as the rebuilt part, scoped to the written boundary. The specification records the untouched systems by name as out of scope, with the date. |
Two reports, two rates
A per-version report: the checklist run against what that version changed, and the specification updated where the version moved a boundary. Usually one page, handed over with the demonstration and the changelog.
A security-week report: the checklist run against the whole product, every part, with the specification written or rewritten in full.
Three things re-trigger it
A new trust boundary — a first outside integration, a first public endpoint, a second organisation's users sharing the product, a move between cloud accounts. A first: personal data, payment data, or a regulated category. An incident — suspected is enough, and the person who suspects it does not have to be right.
The unit is the version
Never the week. The security week is a version like any other — scoped on Monday, tagged on Friday, its report the changelog's companion. That is what makes it a fixed module rather than an upsell.
Our own people's access to your systems is a separate policy, and a different subject from this one: this module governs your product — its roles, its tenants, its secrets, its logs.
The specification: seven parts, in this order, every time
It is written for your engineers to act on after we are gone, so each part states the decision and the reason, never a control name on its own. A part is complete when a reader who did not build the product can name what would have to change to break it.
-
Threat model
What is worth taking, named — not "data". Who would want it, from a fixed attacker list: anonymous internet, an authenticated customer, a user of another tenant, an administrative role, a compromised third-party service, a compromised dependency, a lost or stolen device holding a session. Every trust boundary. And what we are not defending against, named specifically.
Complete when every boundary names the control that holds it, and every asset names who may reach it.
-
Authentication and authorisation
How a user proves who they are; the roles list and what each role may do, written as permissions rather than job titles; where the decision is enforced; session and token lifetime and what ends a session; what a role change and a departure do to existing sessions; and which routes are deliberately unauthenticated.
Complete when the roles list and the unauthenticated route list are both exhaustive — enumerations, not samples.
-
Data isolation
What the tenant boundary actually is in this product — organisation, account, workspace, or the single-tenant boundary that exists instead; where isolation is enforced; and every legitimate crossing, with who may perform it and what is recorded when they do. Support access, administrative override and cross-tenant analytics are crossings and are named as such.
Complete when a reader can say which column, claim or policy decides that a record belongs to one tenant and not another.
-
Secrets
Every secret the product holds — what it is, where it is set, which environment, who can read it, who owns its rotation and how often.
Complete when the list is the whole list, and each row has a named human owner rather than a team.
-
Dependencies
How dependencies are resolved and pinned, including container base images; who receives security advisories for the resolved tree and how often they are reviewed; the route by which an urgent upgrade reaches live; and the licence position — the licence inventory handed over with the version, not a second document.
Complete when the advisory route names a person and a frequency, and the upgrade route has been used at least once.
-
Logging
What is logged; what must never be logged, by name — credentials, tokens, session identifiers, full card or bank numbers, and personal data beyond what the log needs to be useful; how long logs are kept; who can read them; and what watches the product and whom it wakes.
Complete when the never-log list is specific enough to check against, and retention is a number.
-
Incident contacts
Who you contact, by name and by channel, and in what hours; who on our side answers and who escalates; who on your side can decide to take the product offline, which is a business decision and never ours; what counts as an incident worth raising; and the notification path if personal data is involved. Where we process personal data on your behalf you are the controller: we tell you without undue delay, and the decision about notifying a regulator or the affected people is yours.
Complete when every row is a person with a channel, not a role with an inbox — and you have confirmed your own names in writing.
The checklist is the check, and it is adversarial
Eighteen rows. Every one is an attempt that is expected to fail, or an observation made against the running product. We reviewed it is not a result. What is recorded is what was attempted, against what, on what date, and what happened.
| Rows | What is attempted |
|---|---|
| 1 | Walk each trust boundary in the specification against the running product, both directions: every boundary in the document exists in the product, and every boundary in the product is in the document. |
| 2–5 | Call every route with no credentials. Call a privileged route with the wrong role, at the API, not through the interface. Re-use a session after sign-out, after a role change, and past its lifetime. Request another user's record by changing an identifier — and the refusal must not disclose whether the record exists. |
| 6–8 | Signed in as one tenant, request another's records by identifier, by list, by search and by export. Run a query that reaches the stored data with no tenant condition. Check that backups, exports and any analytics copy carry the same boundary. |
| 9–11 | Scan for credentials — this version's commits every version, and the repository's full history in the security week. Read the client-side bundle, error pages and API responses for keys. Perform one rotation end to end, with the product still running and no code change needed. |
| 12–13 | Resolve the tree from the lockfile and review advisories against it; every advisory fixed, or accepted with a written reason and a date to revisit. Confirm base images and build-time installs are pinned, and that this version's licence inventory exists. |
| 14–17 | Follow one request end to end through the logs by its identifier. Search the logs for each item on the never-log list using a test account with known values. Confirm who can read the log store, and that reading it is itself recorded. Cause the monitor to fire and record who was alerted. |
| 18 | Walk the incident contact path with you, end to end. Every contact answers, and your own offline decision-maker is confirmed in writing. |
Every row gets one of five marks
The report carries all eighteen, every time. The first four carry a date; not yet run does not, because nothing has happened to date it.
| Mark | What it means |
|---|---|
| Passed | The attempt was made on the date given and the product behaved as the row requires. A row that failed, was fixed and was re-run is passed, dated the re-run — and the report still records the failure and what fixed it. |
| Failed | The attempt was made, the product did not behave as the row requires, and it is not fixed yet. This is a pre-delivery state: the gap closes before the version reaches you. A failed row is not shipped past. |
| Carried forward | The mark and the date of the last run that produced it, carried unchanged — because this version changed nothing the row reaches, or because the row is one of the three the security week owns. The report always shows when a row was last actually attempted. |
| Not applicable | Only where the product genuinely has no such surface, recorded with the reason and the date it was decided. Never because the surface was not reached. |
| Not yet run | No attempt has been made in this engagement. Every row starts here, and the security week is what empties this column. It is counted in the report, not hidden. |
Checking it yourself
The report is written to be read by whoever holds the product after us, and the current specification travels with it — not a summary of it. Your own engineer, or an auditor you bring, can apply the whole thing without asking us anything.
Re-run three rows
Row 3, a privileged route with the wrong role at the API. Row 6, another tenant's record. Row 15, the never-log list against a test account whose values you know. All three refuse, or come back empty.
Check the specification against the product
Pick one trust boundary from part 1 and one role from part 2. Both are where the document says they are. A specification that has drifted is the failure that makes every later report untrustworthy rather than merely incomplete.
Check that nothing is open without an owner
Every accepted item in the report — an advisory not yet fixed, a control deferred — names a person and the date it is revisited. And every one of the eighteen rows carries a mark, with a date for every mark except not yet run.
If a check was not done, the remedy is not a discount
Being checked against a written security standard is part of the delivery standard itself. A version whose software was not checked fails that standard: we fix it at our cost, and if it still does not meet the standard, you do not pay for that version and anything already paid for it is refunded.
On an independent audit. We have no third-party audit partner named today and we hold no security certification. If your procurement requires an independent audit or a certification, say so at intake — it changes what we quote, and we would rather tell you now than at signature.
How your data is handled
Where we process personal data on your behalf, you are the controller and we are the processor. We process it only on your documented instructions. If your engagement touches personal data, tell us early — it changes the shape of the work, not just the paperwork.
Two questions this section does not answer, because we cannot answer them yet: where processing happens and how transfers are handled, and the data-processing agreement itself. Both are in what we do not have yet, stated rather than implied.
Sub-processors, including AI providers
We tell you which sub-processors and AI providers are used on your work. The list is given for your engagement rather than published as a general one, because it is the tools actually used on your product that you need to review — and it changes.
Notice before a new one, and you may object
We give you notice before adding a new sub-processor or AI provider, and you may object. If you do, we will not use it on your work.
Return and deletion
At the end of an engagement, or on your written request, we return or delete the personal data we hold on your behalf, except where the law requires us to keep it. We keep appropriate technical and organisational measures, the people handling it are under a duty of confidence, and we tell you without undue delay if there is a personal data breach.
If something breaks, who is responsible?
Work lands in your repository continuously and is yours as it lands. Your company is responsible for the software it owns and runs, exactly as it would be if that software had been built by an agency you hired or by engineers on your own payroll. Engaging us does not move that responsibility to us. We are responsible for doing the work to the delivery standard, with reasonable skill and care — and if a version does not meet that standard, tell us and we fix it at our cost; if it still does not, you do not pay for that version, and anything already paid for it is refunded.
§11 of the master agreement is the operative version. It carries the fix-or-refund remedy, what each side's liability is capped at and what the cap does not reach, the losses neither side is liable for, and an indemnity from you for third-party claims arising out of your product, your data and your regulatory position. The agreement is sent on request before any signature.
What we do not have yet
Procurement asks all of these directly. Finding out at signature costs more than reading it here, so here it is.
- No insurance policy. We hold no professional-indemnity or cyber-liability cover, and the agreement warrants none. If cover is a condition of buying, tell us at intake.
- No IP indemnity. The agreement warrants that the deliverables are original or properly licensed, and every component is graded for its licence with the inventory handed over. It does not add a duty to defend a third-party claim. If your template requires one, raise it early — it is the clause most likely to need a conversation.
- No data-processing agreement is in place. The master agreement obliges both parties to enter one where we process personal data on your behalf; none is drafted today. On an engagement touching personal data this goes to the founder before the proposal rather than after it.
- No settled position on processing location or transfers. We do not claim EU-only processing or a standing transfer route, because neither is settled. Ask at intake and you get the answer for your engagement, not a marketing one.
- No third-party audit and no certification. What exists is the specification, the eighteen-row check and the report — ours, dated, and yours to keep and to re-run.
Send us what you have. Our take back within two days.
A link, a repo, architecture notes, or the compliance question you have to answer before anything can be bought.