Cyber Security Built Into Every System, From Design to Audit Evidence

The penetration test report lands just before go-live with critical findings, and the supplier calls every fix a change request. Thornacre’s cyber security service prevents that moment. We design, build, test and monitor the applications, platforms, APIs and cloud environments regulated organisations run, with security in place from the first design decision.

Question	Answer
Who it is for	CISOs, CTOs, IT Directors, Heads of Data, DPOs and COOs in any regulated organisation running customer or staff applications, integrations and cloud environments
The problem it solves	Security flaws found late, in a pen test or audit, when fixes mean the most rework and delay go-live
What we deliver	Threat modelling, secure architecture, penetration testing, vulnerability management, 24/7 monitoring, incident readiness, control mapping
How we work	Secure by design to the NCSC Secure Design Principles, application controls verified against OWASP ASVS, penetration testing to NCSC guidance
Regulations and standards	UK GDPR, Cyber Essentials, OWASP ASVS, ISO/IEC 27001, plus sector security and resilience rules

What problem does cyber security solve for regulated systems?

Cyber security closes the gap between how a system is built or run and how its security must be proved. In regulated organisations, it shows up late: in a penetration test report, cloud review or supplier questionnaire, when fixes mean the most rework.

In the UK government’s Cyber Security Breaches Survey 2025, 74% of large businesses had a breach or attack in the past 12 months. Only 14% of businesses reviewed the risks posed by their immediate suppliers. For personal data, UK GDPR Article 33 requires a breach that risks people’s rights and freedoms to be reported to the Information Commissioner’s Office (ICO).

Each persona meets the problem from a different side:

• The CISO or Head of Security is asked to accept risk on findings that arrive too late to fix.
• The CTO or IT Director sees launches slip while fixes become change requests.
• The Head of Data cannot say where personal data flows once integrations multiply.
• The DPO or Compliance Lead cannot evidence controls when an auditor or client asks.
• The COO carries the operational fallout when a breach takes a system offline.

The root cause is structural, not a failure of your security team: delivery contracts reward features shipped, and the penetration test runs once, just before launch. Every fix then competes with a launch date the board has already announced.

A penetration test is a lagging indicator: it tells you what the design got wrong once the design is too hard to change.

How does Thornacre deliver cyber security across your systems?

Thornacre delivers cyber security as part of building and running each system, so testing confirms the design rather than finding its flaws. For a live system, the steps start from a review. Secure by design is the practice of making security decisions in the architecture before features are built, not adding controls after launch.

1. Scope the threat model. With your security and compliance leads, we map users, integrations, APIs, cloud services, data flows and risks. Where personal data is processed, we run a Data Protection Impact Assessment (DPIA). Outcome: a shared view of risk.
2. Design the security architecture. We apply the NCSC Secure Design Principles, written by the National Cyber Security Centre (NCSC) so that systems “are designed and built securely”. For cloud and APIs we add the NCSC Cloud Security Principles and the NCSC’s API security guidance. Outcome: access control, encryption, hosting and tamper-evident audit logs, decided before build.
3. Build with controls in place. Multi-factor authentication (MFA), role-based access and Single Sign-On (SSO) ship with the first release. Outcome: no control is retrofitted.
4. Penetration test every environment. We try to break the applications, APIs and cloud configuration in development, staging and production, following the NCSC penetration testing guidance and checking controls against the OWASP Application Security Verification Standard (ASVS). Outcome: prioritised findings and a remediation plan.
5. Fix and retest, or sign off. When findings are raised, we fix them ourselves and retest. When the report is clean, your security lead approves go-live with the report as evidence.
6. Monitor, patch and prepare. We run 24/7 monitoring and continuous scanning of code and cloud set-up, with every issue tracked by severity until closed, as the NCSC vulnerability management guidance recommends. An incident response plan, written to the NCSC incident management guidance, links to your continuity plans. Outcome: issues closed and a response plan ready.
7. Hand over the evidence. We supply test reports, patch records and audit results throughout. Outcome: answers ready when an auditor asks.

The diagram below shows the seven steps, including the branch after the penetration test.

What do you get from a Thornacre cyber security engagement?

A Thornacre cyber security engagement leaves you with controls and records you keep, not a one-off report.

Deliverable	What it gives you
Threat model and data flow map	Where data goes, who can reach it and which risks you accepted
Security architecture design	Access, encryption, hosting and logging decisions made before build
Penetration test reports	Findings, remediation plans and retest results for every environment
Patch and incident records	Each issue tracked and closed against agreed SLAs, with tamper-evident audit logs
Incident response plan	Roles, escalation and recovery steps agreed before an incident
Control mapping	Each control mapped to NCSC principles and OWASP ASVS, ready for supplier questionnaires

The same controls underpin our PCI-compliant payment platforms and the hosting set up by our cloud migration and DevOps service.

Which regulations does cyber security engineering help you meet?

Cyber security engineering helps you meet UK GDPR security duties, recognised cyber standards and the security rules in your sector. The service supplies the controls and the evidence; your organisation still owns the compliance decision.

Three standards apply across every regulated sector:

• UK GDPR Article 32 requires “appropriate technical and organisational measures to ensure a level of security appropriate to the risk”, tested regularly. Encryption, access control and scheduled penetration tests answer it.
• Cyber Essentials sets five technical controls against common attacks. All five are designed into each system we build or run.
• OWASP ASVS gives testable security requirements for web applications and APIs. Authentication, session and access controls are verified before each release, and the records support an ISO/IEC 27001 information security management system.

Sector rules then add their own expectations:

Sector	Regulation or framework	What it requires	How the service addresses it
Banking and payments	FCA operational resilience (PS21/3)	Important business services mapped and tested to stay within impact tolerances, from 31 March 2025	Monitoring, incident response and tested recovery
Private healthcare	Data Security and Protection Toolkit	Organisations with access to NHS patient data and systems must use the toolkit	Controls and test evidence mapped to toolkit standards
Life sciences and pharma	EU GMP Annex 11	Access restricted to authorised people, access changes recorded, data changes logged with identity and time	Role-based access and tamper-evident audit logs
Energy, water and critical infrastructure	NCSC Cyber Assessment Framework (CAF)	Security outcomes for operators under the NIS Regulations 2018	Design records, logging and monitoring mapped to CAF outcomes
Public sector	Service Standard point 9	Create a secure service which protects users’ privacy	Secure by design architecture and DPIA support

“Appropriate to the risk” is judged after an incident. Without a threat model and test history, you cannot show what you judged appropriate, or why.

How do you choose between a one-off pen test and built-in security?

Choose a one-off penetration test when a system is stable and you need a point-in-time check. Choose built-in security when the system is new, changes often or handles regulated data.

Criterion	One-off penetration test	Security built into delivery
When findings appear	Just before launch	During design and each release
Effort to fix	High: rework after build	Low: changed in design or sprint
Evidence for auditors	One report, one date	Threat model, test history, patch records
Flaws found after launch	Missed until the next test	Caught by continuous scanning

Apply these rules:

• If the system is still being designed, build security in.
• If the system is live and stable, start with a penetration test, then decide on monitoring from the findings.
• If a regulator or client needs independent assurance, add a test from a separate provider.

When is built-in cyber security not the right choice?

Built-in cyber security is the wrong choice when you need an independent tester, cover for end-user devices, or assurance on a vendor’s own infrastructure.

• Independent assurance. Our testing covers systems we built or run. When an auditor needs independence, also commission a separate CREST or NCSC CHECK provider.
• End-user devices. Our monitoring covers applications, integrations and cloud. Laptops, email and office networks need a managed security operations centre.
• Vendor SaaS. A vendor’s own assurance covers the vendor, not your configuration. We review your configuration and integrations; the vendor evidences its own infrastructure.

The usual objection is that outsourcing adds risk. A stretched internal team often carries more risk than a supplier that designs to NCSC principles, tests every release and keeps the evidence. Ask any supplier for its test reports and how its controls map to the standards you must meet.

Waiting adds work: every release built without a threat model adds controls to retrofit later.

Frequently Asked Questions

What does a cyber security threat model cover?

A threat model covers every route data takes through a system: users, administrators, APIs, integrations, cloud hosting and third-party components. For each route it records who can reach the data, what could go wrong and which control answers it. Where personal data is involved, the threat model feeds the Data Protection Impact Assessment, so privacy and security risks are judged together.

Can built-in security work with our existing security operations centre?

Built-in security works alongside an existing security operations centre (SOC). Thornacre monitors the systems it builds or runs, and can forward alerts and audit logs to your SOC so your analysts see one picture. Your SOC keeps end-user devices; Thornacre keeps the systems, their patching and test history.

What happens if a critical vulnerability is found after go-live?

A critical vulnerability found after go-live is treated as an emergency and fixed first. Every patch follows one path: triage, backup, staging, testing, then release, so nothing reaches a live system untested. Each issue is logged against the agreed SLA.

Does built-in security make our organisation compliant?

Built-in security gives you controls and evidence, but compliance stays your organisation’s decision. The threat model, test reports and patch records show security appropriate to the risk for each system. Your policies, staff training and wider estate still sit within your own compliance programme.

How do we start a cyber security engagement?

Start with a security assessment workshop. We review your systems, data flows and compliance duties with your security and compliance leads. Bring your latest penetration test report. You leave with a ranked list you can act on, with or without Thornacre.

---

If a penetration test or audit is coming up, book a security assessment workshop. We will review your controls and evidence and tell you what to fix first. Email hello@thornacre.com, or see our work in regulated environments and our custom software development service.

This page is general guidance only; consult your legal or compliance team for your specific requirements.