Skip to main content
// FOUNDRY5
Enterprise security review

Gate four of four, and the one where somebody inside the buyer has already chosen you. Their security function decides whether that choice survives, and your champion argues your case in a meeting you will never attend. A slow answer rarely brings a rejection. The review stops moving, and a quarter later the deal has gone cold.

✓ The evidence is assembled here · Independent testers do the testing

9Pack items we assemble
5Days to a reusable pack
0Penetration tests we run ourselves
The procurement pack

Nine things the security review will ask your champion for.

A regulator is neutral at best. An enterprise buyer has a champion who wants your product and a security function that did not choose it and feels no hurry. Every gap in your pack is something the champion explains for you, from memory.

Not every buyer asks for all nine, and the order varies. Assemble them once and the fourth enterprise deal stops being a project.

Where the line is
  • Your buyer decides what they require

  • The evidence is assembled here, and the product is built to it

  • Independent testers test it

  • Testing and auditing your security is never our job

In Philip's words
The champion inside your buyer has put their name next to yours. Hand them a pack they can forward without editing, and you have done the most useful thing a supplier can do for that deal.

Philip Wasko

Co-founder, Foundry 5

01

What you are

What the review asks · 01

A completed security questionnaire, in whatever form your buyer sends it.

What that means for the build

A spreadsheet of a few hundred rows, sometimes a portal. Every answer has to be true, consistent with the others and consistent with the product, and that third test catches the most suppliers.

What the review asks · 02

An architecture and data flow diagram showing where customer data goes.

What that means for the build

The pitch-deck diagram will not do. This one shows where a record physically sits, which services touch it, and what crosses a boundary you do not control.

What the review asks · 03

A list of every sub-processor in the chain.

What that means for the build

Every third party that can touch customer data, including the tool somebody added during a sprint and nobody wrote down. Buyers increasingly check the list against what they can observe.

02

What you do

What the review asks · 01

How access is granted, reviewed and removed, and whether you can prove it happened.

What that means for the build

Offboarding gets the hardest questions: when access went, for whom and who approved it, shown eighteen months after the person left.

What the review asks · 02

What you do when something goes wrong, and how fast you would tell them.

What that means for the build

Named roles, a severity model and a notification commitment you would put in a contract. A statement that you take security seriously answers none of it.

What the review asks · 03

What happens if your infrastructure, or your company, has a bad day.

What that means for the build

Recovery objectives you have tested, backups somebody has restored from, and an honest answer about what your buyer loses in the worst case.

03

What you carry

What the review asks · 01

A recent penetration test, run by somebody independent of the build.

What that means for the build

Recent matters and independent matters. A test run by the team that wrote the code answers a different question, and reviewers know it.

What the review asks · 02

A data processing agreement their legal team will accept.

What that means for the build

Usually theirs, usually with edits. It commits you to things the product has to do, so engineering should read it before anyone signs.

What the review asks · 03

Evidence that you carry the cover their procurement policy requires.

What that means for the build

Professional indemnity and cyber cover at the levels their policy sets. Arranged early it is a formality. Discovered missing two weeks before signature, it moves the signature.

Who this is not for

Procurement projects we step back from, and why.

A security review runs on somebody in your company answering fast and with authority. Without that person the delay is structural, and documentation cannot fix it.

Where it goes wrong

What stalls a secure product in procurement.

Each is a secure product that cannot prove it fast enough, which in a procurement cycle has the same commercial result as an insecure one.

01 Repeat

The pack is rebuilt for every deal

Nothing was kept, so each deal starts with the same three weeks of archaeology, like rewriting your CV from memory for every application. By the fourth deal, a quarter of engineering time has gone on questions already answered.

02 Gap

The answer and the product disagree

Somebody optimistic filled in the questionnaire. Then a reviewer asked to see what an answer described, and it was still on the roadmap.

03 Chain

An undeclared sub-processor turns up

A tool added during a sprint never reached the list. The buyer finds it before you remember it, and every other answer gets re-read with less goodwill.

04 Record

Offboarding left no trace

Access was removed and everybody remembers doing it. The record of when and by whom is missing, and the record is the only answer a reviewer accepts.

The Week-One Review

Five days that turn the questionnaire into a pack you can reuse.

The procurement version is built for reuse, because you will face this gate again next quarter, with a different buyer asking most of the same questions.

  • Day 1 · Name the gate: the buyer, what they sent, and who on their side owns the review
  • Day 2 · List the evidence: the nine items mapped honestly against what already exists
  • Day 3 · Test the plan: every questionnaire answer checked against the running product
  • Day 4 · Decide the sequence: what needs building, what needs writing down, and in what order
  • Day 5 · Price it: a pack structure, a build sequence for the gaps and a fixed quote

5 days

The fee is quoted before you start and credited against the build when you proceed.

What you walk away with

A pack your champion can forward without rewriting it.

Yours to keep whether or not the build happens here.

  • A reusable pack structure, where you had one deal's worth of answers
  • An honest gap list, split into build work and documentation work
  • A sub-processor inventory that matches what is running
  • A response plan for the follow-up questions, which always come
The proof

Senior Stairlifts, and the controls a buyer asks about.

Senior Stairlifts is one of London’s leading stairlift companies. Its CRM holds the whole customer journey, from enquiries, surveys and quotations through installations, invoicing, payments and aftercare, which is the kind of business-critical data a security review asks hard questions about.

So the controls were part of the build from the start. User permissions and data relationships were planned as part of the architecture, and every change goes through code reviews, automated testing and controlled releases.

The modernised platform has gone live, with data transferred and essential workflows validated through a structured migration. You can also ask for a walk through the structure of a security pack, item by item, so you judge the work for yourself.

Read the Senior Stairlifts case study
Senior Stairlifts CRM platform
Enterprise security

Senior Stairlifts

5

Business workflows unified in one CRM

The regulatory loading

The gate that comes back at every renewal.

FCA authorisation, a clinical submission and an app review are events with a date on them. A security review returns with every new enterprise customer and every annual re-assessment, and the pack decays in between as the product changes.

That is why this page points at an ongoing engagement. Expect one enterprise customer and no renewal, and you will be told the retainer does not apply.

Ask for a quote
Band 3 · Embedded team

Quoted after the Week-One Review

  • Monthly engagement
  • The same team across reviews
  • Evidence maintained, not rebuilt
  • Roadmap sequenced around review dates
Security review questions

Asked by teams halfway through a security questionnaire.

All six are about getting your product through somebody else's review. None is a security assessment, and we are not qualified to give one.

A common position, and a recoverable one. Most teams reach their first enterprise deal with nothing written down, because nothing required it. The work is assembling it once, properly, before a deadline forces three rushed versions.

Ask your buyer before you assume. Some require a named certification. Many accept a well-evidenced pack, particularly from a company your size, and choosing a framework nobody asked for is an expensive way to pick the wrong one.

Longer than anyone plans for, and the variable you control is your response time. A question answered inside a day keeps it moving. One left for three weeks is how a deal goes cold without anybody saying no.

The same questions, plus whatever changed. A pack built to be maintained makes it an afternoon. One assembled for a single deal makes it the original project again, with less patience on the other side.

Both. You inherit good answers on physical security and resilience, and the duty to declare every provider in the chain. An undeclared provider reads far worse than an unusual one.

Usually, and the second attempt can move faster, because the buyer has told you what is missing. Your champion has already spent credibility on you once, so the resubmission has to look different, not slightly better.

Nine items / One champion / One renewal cycle

Tell us who is buying and what they have sent you.

Forward the questionnaire if you have one. You will hear which answers you already have, which need writing down, and which need building first.

TESTING BELONGS TO INDEPENDENT TESTERS / THE EVIDENCE PACK BELONGS TO YOU