Compliance is the set of rules that govern how a business collects, stores, and protects other people's data — and the evidence that shows you follow them. For a small business, the practical question is never "do we comply with everything?" It is narrower: which of these frameworks actually applies to us, and what does it ask us to do first?
Compliance frameworks sound like a foreign language, and the acronyms don't help. But for most small businesses the reality is simpler than it looks: the frameworks overlap heavily, and they all point toward the same basic security hygiene. What follows is a plain-English map of which rules apply to you and where to start.
Which frameworks actually apply to your business?
That depends on the data you hold and the customers you sell to, not on your size. Most small businesses land under one or two of these, not all four. HIPAA is included here so you can recognise it if you see it; IronWall Cyber Solutions does not work with healthcare or HIPAA-governed organisations.
| Framework | Who it applies to | What it actually asks for |
|---|---|---|
| GDPR | Anyone holding personal data about people in the EU or UK, wherever you are based | Collect only what you need, protect it, and honour access and deletion requests |
| PCI DSS | Any business accepting credit or debit card payments | Keep card numbers out of your systems, then confirm that in a short annual self-assessment |
| HIPAA | US healthcare providers and the vendors handling health information for them | Documented safeguards over how that information is stored, accessed, and shared |
| SOC 2 | Software and service firms whose business customers ask for assurance | An independent audit showing your security controls work as described over time |
How much do these frameworks overlap?
Almost entirely, once you look past the vocabulary. Treating each framework as a separate project is exhausting and wasteful, because underneath the acronyms they ask the same handful of questions: what data do you hold, who can reach it, how is it protected, and what happens when something goes wrong. The controls that answer those questions are built once and counted several times, whether the auditor calls them safeguards, requirements, or trust criteria.
That is why the sensible sequence for a small business is fundamentals first and framework-specific paperwork second. The reverse order — reading a standard end to end before securing anything — is where owners lose months.
Get the security fundamentals right and you are most of the way toward every framework at once.
What does compliance actually ask of a small business?
Less technology than owners expect, and more record-keeping. The single biggest lever on card payments is scope: if a reputable payment processor handles the card numbers and they never touch your own systems, your PCI obligations shrink dramatically, often to a short self-assessment questionnaire rather than a full audit. Privacy law scales the same way. The less personal data you collect and keep, the less there is to protect, explain, and eventually delete.
SOC 2 sits apart from the others because it is not a law at all. It is a voluntary audit you choose to undergo so that buyers can see how you handle their data. The work is largely writing down what you already do, doing it consistently, and keeping the evidence — which is why the frameworks feel heavier to businesses that have never documented anything.
What do you do when a customer asks for proof?
Answer plainly, and treat the request as a sales document rather than an exam. As you move upmarket, security questionnaires start arriving before contracts do, and a buyer's procurement team is usually checking that someone at your company owns the answer — not that you hold every certification in existence.
Say what is true today, name the person responsible, and give a realistic date for anything still in progress. A short, specific answer builds far more confidence than a vague claim that quietly overstates your position, and an overstatement is the one thing that will cost you the deal later. Keep a single folder of your current answers, policies, and access records so the second questionnaire takes an hour rather than a week. That folder is also, conveniently, most of what an auditor would ask to see.
Where should you start?
With the work that pays off under every framework at once, in this order.
- Map your data first. You cannot protect what you have never inventoried, so list what you collect, why you collect it, where it is stored, and who can reach it. Almost every other requirement depends on this one.
- Fix access and encryption next. Least privilege, multi-factor authentication, prompt removal of former staff, and encryption in transit and at rest appear in every framework and block real attacks along the way.
- Write your policies down. Auditors, regulators, and enterprise buyers all want evidence rather than intentions, and a policy nobody has recorded is indistinguishable from no policy.
- Get an outside look at your exposure. An external review shows what your business actually presents to the internet and gives you a prioritised, defensible place to begin.
The bottom line
Compliance is not about memorising acronyms. It is about handling data responsibly and being able to prove it. Start with the fundamentals every framework shares, document as you go, and the specific requirements become far less daunting.