Cybersecurity · Governance and compliance
Certification that follows naturally from how you work
We implement ISO 27001, SOC 2, Cyber Essentials, DORA and NIS2 as controls that run and produce their own evidence. The aim is for an audit to become a report from your systems, rather than a project that stops everything else.
Where this starts
Compliance often costs the most in the wrong places
The expensive part of certification is rarely the certificate itself. It is the six weeks before the audit, when engineers stop building and start collecting screenshots. It is the sales deals delayed by questionnaires that nobody owns, and the controls that only operate for one month a year. Auditors are not the problem. The problem is evidence that has to be created specially, rather than produced by the systems as they run.
What we usually find
- Evidence gathered by hand in the weeks before an audit, then thrown away
- Policies written to satisfy a standard, which the teams they describe do not recognise
- A risk register kept for the auditor rather than used to make decisions
- Security questionnaires answered from scratch each time by whoever is free
- Controls owned by the security team that only the engineering team can actually operate
- Two or three frameworks implemented separately, even though they cover the same controls
Our position
A control that only works during audit season is not really a control, and everyone involved knows it.
What the work covers
We implement the controls, not just interpret the standard
Many firms will tell you what a standard requires. The work that makes a difference is turning each requirement into something that runs, owned by someone who understands their responsibility.
One set of controls for every framework
ISO 27001, SOC 2, Cyber Essentials Plus and PCI DSS overlap heavily. We implement one set of controls and map it to each framework. A second certification then only needs evidence, rather than a whole new programme and budget.
Policies that match what teams do
We write policies based on what your teams actually do, and keep them under version control alongside the systems they cover. A policy that nobody follows is an audit finding waiting to happen.
Risk management that informs decisions
We build a risk register based on real business impact. It is reviewed whenever things change, not just on a fixed date, and decisions about each risk are recorded where the engineering work is planned.
Supplier and third-party risk
We carry out checks on your suppliers in proportion to the risk they pose, show where you depend too heavily on one supplier, and set contract requirements that match what you can actually monitor. This is becoming a major focus of assessments under DORA and NIS2.
Sector regulations
This includes DORA for financial services firms, NIS2 for essential and important organisations, and UK GDPR for everyone. We establish which rules apply to you, what they mean day to day, and what really has to change. That is usually less than a vendor will tell you, but more than you hoped.
Customer assurance
We maintain a library of answers to security questionnaires and a public trust page. As a result, a customer’s security review can speed up a sale rather than holding it up for weeks.
How it stays fixed
Evidence produced by your systems
A good compliance programme is measured by how little anyone has to do in the month before an audit.
- Mapping
- Each control is mapped to every framework it satisfies. Evidence collected once counts for all of them, and nobody collects the same item twice.
- Collection
- Evidence such as access reviews, change approvals, scan results and training records is collected from your systems on a schedule. It is dated, attributed and stored, rather than captured as screenshots.
- Automated checks
- Technical controls are checked automatically by the pipeline. If your systems stop matching what your policy says, something visibly fails.
- Exceptions
- Every exception has an expiry date, an owner and is visible to everyone concerned. This is what makes the exception process credible to an auditor, rather than a documented way around the control.
- Reporting
- Your board sees an ongoing view of control health, built from the same data as the audit evidence. There is only ever one version of the truth.
What you are left with
- One set of controls, mapped to every framework you are asked about
- Evidence collected automatically, dated and attributed
- Policies your engineers recognise as a description of their own work
- A library of questionnaire answers that speeds up security reviews
- A board report built from the same data as the audit evidence
Tell us which certification is holding up a deal
We will tell you what is really missing, what you already meet but have never evidenced, and how long it will take to close the real gap.