Security & Governance
Operating principles, not checkbox.
Seven principles guide every Failsafe engagement. They are not security theatre. They describe how we treat your data, your workflows and your team's trust on the day the discovery interview starts and on the day the report is delivered, and in between.
Operating philosophy
Governance sits inside the methodology, not next to it
Security and governance do not live at the end of a project. They sit inside every stage of the Failsafe Method — Discover, Assess, Prioritise, Select, Implement, Optimise — because most of the risk to a business comes from assumptions made before any change is designed. The seven principles on this page are the operating contract of everyday work, not a written summary of a posture held on engagement-letter signature.
We do not publish policy numbers, insurer names or cover values on the website. The work is operating insurance. Where the seven principles describe how we handle information, that's what they cover. Where additional structural reassurance is needed — third-party penetration testing, a stand-alone cybersecurity audit, a sector-specific compliance review — those are scoped separately and not part of a Business Performance Review.
The seven principles
How every engagement operates
Each principle is named below; the paragraph beneath it describes what it means in practice during a Failsafe engagement.
-
1
Client data stays with the client wherever possible
The diagnostic work reads from a client's existing systems, processes and people; it does not extract data into a Failsafe-owned store. Where a small piece of evidence is brought into our working set, it is described in the engagement letter, stored only for the duration of the engagement, and deleted at the end. There is no Failsafe-side analysis lake; there is no central pipeline of client data.
-
2
Client workflows belong to the client
Recommendations may suggest a process change; they do not lock a client into a Failsafe-built workflow. Every artefact we produce is owned by the client. Every implementation is owned by the client or a third party chosen by the client — not by Failsafe.
-
3
We request the minimum permissions required
Where the diagnostic reads a system, we read with the smallest permission available that still allows the work. Credentials are scoped read-only where possible, time-boxed, and withdrawn on engagement end. We do not request owner-level access as a matter of routine.
-
4
We document every integration and data flow
If we touch a system or set up an integration, the client receives a written description of every data flow before it goes live. That documentation is owned by the client. Where an engagement ends, it remains accurate and current.
-
5
Security by design
Every recommendation is evaluated for security before it is recommended. Where a change introduces new exposure, that exposure is named in the report and remediation is part of the priority list — not a separate workstream after the BPR.
-
6
Privacy by design
Personal data is treated as personal throughout. Recommendations about process changes flag privacy implications. AI recommendations, where they appear, carry a privacy review as a precondition — data minimisation, retention, lawful basis and third-party handling named in the report.
-
7
Governance from day one
The Governance Review delivered as part of every Business Performance Review is not a separate framework chosen later. It is the seven principles above applied to the client's existing decision rights, permissions, integrations and documentation gaps, scored and prioritised as an output of the BPR.
Insurance as reassurance, not headline
Professional Indemnity and Public Liability
Insurance is operating cover. It is one signal among several that the work is set up professionally. The seven operating principles above describe the day-to-day posture; the insurance statement provides structural reassurance for engagements that involve written advice. We do not publish cover values, policy numbers or insurer names on the website. Cover arrangements are described in the engagement letter.
Technology we choose
How we evaluate recommendations
We evaluate every technology we recommend against the seven principles before recommending it. Vendor neutrality is the default posture, but vendor neutrality is not the absence of preference — it is the presence of a structured evaluation: does the technology handle the data appropriately, is its security posture compatible with the engagement's posture, and is the operational fit with the client's existing stack well-evidenced. Where a vendor is appropriate to recommend, the rationale is documented; where it isn't, the rejection is documented. There is no commercial relationship that changes this.
Working securely together
What good practice looks like on the client side
- Designate a primary contact who has authority to discuss data flows and access scope.
- Treat the engagement-letter access list as a working document. If a permission is no longer needed, we remove it.
- Flag any data subject rights requests, regulatory enquiries or data-loss events that occur during the engagement so our recommendations can accommodate them.
- Keep written records of the engagement. The report you receive is yours; it should be filed under your normal governance rather than left in personal inboxes.
Engage under these principles
If the seven operating principles align with how you want a consultancy to work, the next step is the booking enquiry.