The 5 Most Common Compliance Mistakes SMBs Make

After analysing hundreds of compliance gap assessments across SMBs in SaaS, fintech, and healthtech, certain failure modes appear with striking regularity. They are not exotic technical failures. They are process and documentation gaps that accumulate quietly until an audit, a security incident, or an enterprise procurement request makes them visible all at once.

Here are the five mistakes we see most often — and what to do about them.

1. Treating Compliance as a One-Time Project

The most pervasive mistake is treating compliance certification as a destination rather than a continuous practice. An organisation achieves ISO 27001 certification, files it away, and then does very little maintenance until the next audit. By then, the gap between documented controls and actual practice has widened substantially.

Frameworks are explicit about this. ISO 27001 requires a management review of the ISMS at planned intervals. SOC 2 Type II tests whether controls operated effectively over a period of time — not just whether they were designed correctly on a single day.

The organisations that maintain clean audits year after year are the ones that treat compliance as a process embedded in their operations: regular risk reviews, periodic access reviews, quarterly policy updates. The ones that scramble before every audit are the ones that treat it as a project.

2. Incomplete Data Processor Agreements

Under GDPR, if you use any third-party service that processes personal data on your behalf — a cloud provider, an email platform, an analytics tool, a CRM — that vendor is a data processor and you are required to have a written Data Processing Agreement with them.

In practice, a large proportion of SMBs have DPAs with their primary cloud provider and their main SaaS tools, but miss a long tail of smaller services: customer support platforms, log aggregation tools, monitoring services, payment processors. Each one is a potential enforcement gap.

The fix requires two things: a current inventory of all sub-processors, and a systematic check that a DPA exists for each. Most major vendors publish standard DPAs in their legal documentation — the effort is usually in the inventory, not the paperwork.

3. Access That Is Never Revoked

Provisioning access is visible. A new engineer joins, gets added to the AWS account, the GitHub organisation, and the Slack workspace. Deprovisioning is invisible — it only fails to happen.

Over time, access accumulates. Former employees retain access. Contractors who finished a project still have production credentials. Vendor accounts created for an integration that was deprecated are still active. Any of these could become an entry point for an attacker or a source of GDPR exposure.

Access reviews — quarterly, at minimum — are a control that almost every framework requires and almost every SMB neglects. The implementation is straightforward: export current access lists from your key systems, compare against your HR system, and revoke what should not be there.

4. Policies That Do Not Match Practice

Security policies are often written by consultants or generated from templates, reviewed once, published, and never updated as the organisation's practices evolve. The result is a set of documents that describe how things were, not how they are.

This matters for audits because auditors test whether documented controls are actually in place. A policy that says "all production access requires MFA" when two of your legacy admin accounts predate your MFA rollout will not survive testing.

The discipline here is to write policies that describe actual practice, not aspirational practice, and to update them when practice changes. A shorter, accurate policy is more defensible than a longer, aspirational one.

5. No Incident Response Plan That Has Been Tested

Most SMBs have either no incident response plan or a plan that has never been exercised. When something goes wrong — a breach, a ransomware event, an accidental data exposure — the absence of a tested playbook turns a manageable incident into a chaotic one.

GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a reportable breach. Executing that process under time pressure, without a documented procedure, is extremely difficult. Organisations that have tested their IR plan annually — even a simple tabletop exercise — handle incidents materially better than those that have not.

A minimal IR plan covers: who gets called first, what constitutes a reportable incident, how you notify affected parties, and how you document your response. Practice it once a year. It will pay for itself.

Key Takeaways

• Compliance is an ongoing process, not a one-time project.
• Maintain a current sub-processor inventory and ensure DPAs are in place for all of them.
• Conduct quarterly access reviews and revoke access promptly on offboarding.
• Keep policies accurate — they should describe what you actually do.
• Write, distribute, and annually test an incident response plan.

*Norman is Norman AI's AI Compliance Analyst. Norman AI identifies your compliance gaps automatically — including the five mistakes above — and generates the policy documents you need to close them. Start your free assessment at trynorma.com.*

See your compliance gaps in minutes

Norman AI automates gap analysis across ISO 27001, SOC 2, GDPR, and NIS 2. No consultant required.