Notes from the team.

Most GDPR programmes start well: a data audit, a set of policies, a signed-off register of processing activities. Then the business moves on, and the paperwork doesn't move with it.

New tools get adopted without a data protection impact assessment. New hires never see the policy that was written before they joined. A new supplier gets access to customer data with nobody checking their own compliance posture.

The fix isn't more paperwork up front, it's a review cadence: quarterly checks on your processing register, a light-touch DPIA baked into how you evaluate new tools, and onboarding that actually includes data handling training. We build that cadence into the engagement, not as a one-off audit that goes stale the day we leave.

A good penetration test isn't a surprise audit designed to embarrass your engineering team. It's a scoped, agreed simulation of how a real attacker would approach your systems, with rules of engagement both sides sign off on before anyone touches a keyboard.

We start with scoping: which systems, which methods, which hours are in bounds. Testing typically runs one to two weeks depending on scope, covering reconnaissance, exploitation attempts, and — critically — an assessment of what an attacker could actually reach if one weakness held.

The report that follows should read like a priority list, not a wall of CVE numbers: what's exploitable today, what's a theoretical risk worth watching, and what to fix first given your actual threat model. We walk every client through it live, because a PDF nobody reads doesn't make you any safer.

We still see it constantly: a site built well, launched confidently, then left running the same plugin versions for years because "it still works." It does, right up until it doesn't.

Outdated CMS plugins are one of the most common entry points for opportunistic attackers, who scan for known vulnerabilities at scale rather than targeting any one business specifically. You don't need to be interesting to get hit; you just need to be unpatched.

The fix is unglamorous: a maintenance plan that actually runs — dependency updates, staging-tested before they go live, plus monitoring that flags anything unexpected. It costs a fraction of a breach, and none of the reputational fallout.

SOC 2 gets treated like a badge to slap on a website, but it's closer to a structured argument: here is what we said we'd do to protect customer data, and here is the evidence that we actually did it, consistently, over the audit period.

The five trust service criteria — security, availability, processing integrity, confidentiality and privacy — sound abstract until you translate them into daily practice: access reviews that actually happen on schedule, incident response that's been tested rather than just documented, change management with a real audit trail.

Type II audits are where most businesses get caught out, because they test whether controls operated consistently over months, not whether they existed on the day of the audit. We help clients build the evidence trail as a by-product of how they already work, rather than a scramble the week before the auditor arrives.

The projects that sail through security review aren't the ones with the most expensive tooling, they're the ones where security decisions were made at the same time as architecture decisions, not retrofitted after a scary email from a client's security team.

That means authentication and authorisation modelled properly from the first sprint, dependencies tracked and kept current automatically, and input validation treated as a default rather than a checklist item added before launch.

It also means code review that includes a security-minded second pair of eyes, not just a functional one. We build this in as standard on every engagement, because retrofitting security into a finished application is always slower and more expensive than designing it in.

You've grown past the point where one person understands every system. You're handling more customer data than you were twelve months ago, or a new integration means a third party now touches it too.

A customer or partner has started asking security questionnaire questions you couldn't answer confidently. You're preparing to raise funding or go through due diligence, and you know security will come up. You've had a near-miss, even a small one, and it rattled you more than you expected.

Any one of these is reason enough to get a baseline audit done on your own terms, before it's forced on you by circumstance. It's cheaper, calmer, and you get to set the timeline.