How to Become Compliant: A Step-by-Step Guide (2026)

If you have landed here typing "how to become compliant" into a search box, you are almost certainly staring at a framework name, a customer questionnaire, or a regulatory deadline, and wondering where on earth to start. The good news: becoming compliant is not a mystery. Whether the target is ISO 27001, SOC 2, GDPR, DORA, NIS2, the Cyber Resilience Act, HIPAA, or PCI DSS, the underlying path is the same repeatable process. This guide walks the whole thing, end to end.

One clarification first, because "compliance" means different things to different people. This guide is about information security, data protection, and regulatory compliance: the world of security frameworks, privacy law, and cybersecurity regulation. It is not about business licensing or tax filing. If your question is really "how do I get SOC 2" or "how do I comply with GDPR," you are in the right place.

Here is the shape of the journey. Seven steps, each of which we unpack below.

What “becoming compliant” actually means

Before the steps, three distinctions that save a lot of wasted effort.

Frameworks versus regulations

A framework is a voluntary standard you choose to adopt, usually because customers ask for it. ISO 27001 and SOC 2 are frameworks. A regulation is a law you must follow because of what you do or where you operate. GDPR, DORA, NIS2, and the Cyber Resilience Act are regulations. The practical difference: with a framework you can pick your scope and timeline, whereas with a regulation the scope and the deadline are set for you. Most organisations end up carrying a mix of both.

Certification versus attestation versus self-assessment

“Compliant” can be proven in three ways, and it matters which one your customer or regulator expects:

• Certification. An accredited body audits you and issues a certificate. ISO 27001 works this way. The certificate is the deliverable.
• Attestation. An independent auditor examines your controls and writes a report describing what they found. SOC 2 works this way. There is no pass or fail stamp, there is a report that a customer reads.
• Self-assessment. You assess yourself against the requirements and declare conformity, sometimes with a questionnaire. Many regulatory regimes and lower tiers of PCI DSS work this way. The burden of honesty is on you, and the penalty for getting it wrong lands later.

What an assessor is really checking

For every requirement, an auditor asks the same three questions in order. Does a control exist? Is it documented? Is there evidence it is actually operating? A control that exists in someone’s head fails the second question. A beautifully written policy that nobody follows fails the third. Getting compliant is, in the end, the work of being able to answer yes to all three for every requirement in scope.

Step 1: Work out which frameworks and regulations apply to you

You cannot become compliant with everything, and you should not try. The first job is to figure out what actually applies. Applicability is triggered by what you do, not by an appetite for certificates. A handful of questions usually settles it.

Work down the triggers that describe your business. If you sell software to enterprises, one of them will eventually demand SOC 2 or ISO 27001 in a security review. If you process the personal data of people in the EU or UK, GDPR applies regardless of where you are based. If you are a bank, insurer, or an ICT provider serving them in the EU, DORA is not optional. If you operate essential or important services in the EU, NIS2 reaches you. Take card payments and PCI DSS is in scope. Sell a product with digital elements into the EU market and the Cyber Resilience Act brings it into scope, with its core obligations applying from December 2027.

Two things surprise people at this stage. First, you almost always have more than one obligation at once: a European fintech can easily be inside GDPR, DORA, and NIS2 simultaneously. Second, the overlap between them is enormous. That overlap is the single biggest lever you have for doing this efficiently, and we come back to it near the end.

Step 2: Run a gap analysis to find where you stand

A gap analysis is a structured, honest look at where your current reality falls short of a framework’s requirements. It is the difference between guessing and knowing. People confuse it with an audit, so here is the clean distinction: a gap analysis is how you prepare, and an audit is what you prepare for. You run the gap analysis on yourself, as often as you like. The audit is done to you, on a schedule, by someone else.

The mechanics are simple. Take every control in the framework, and rate how mature your handling of it is today. A common scale runs from zero to four.

The temptation is to be generous with yourself. Resist it. A gap analysis that flatters you produces a remediation plan that misses the real work, and the truth surfaces later at the worst possible moment, in front of an auditor. Score a control as established only if you could point at evidence today. In practice most first-time gap analyses come back with a lot of ones and twos, and that is completely normal. The score is a starting line, not a verdict.

The output you want from this step is not a percentage. It is a ranked list of specific gaps, each attached to a specific control, so that step three has something concrete to chew on. If you take one thing from this section: assess across every area before you start fixing anything. The most expensive mistake teams make is pouring months into the two areas they understand while genuine gaps sit untouched in the areas they never looked at.

Step 3: Prioritise and fix the gaps

Now you have a list of gaps. You cannot close them all at once, and you should not try to close them in the order they happen to appear. Prioritise on two axes: how much risk the gap carries, and how much effort closing it takes. Attack the high-risk, low-effort items first. They buy you the most safety for the least work and build momentum.

Sort your remaining gaps into three buckets:

• Quick wins. Enable multi-factor authentication, turn on logging, write the one policy that was missing. Days, not months.
• Process changes. Introduce access reviews, a formal incident procedure, a vendor onboarding checklist. These need a human to own them and a cadence to run them.
• Heavy lifts. Encryption programmes, network segmentation, a full business continuity capability. Plan these deliberately and give them a real owner and budget.

Assign every remediation item an owner and a due date. A gap with no owner does not get closed. This is also the moment to build a roadmap you can actually track, so that progress is visible to the people who care about the deadline.

Step 4: Write policies that match reality

Every framework wants policies: an information security policy, an access control policy, an incident response plan, and so on. It is tempting to download a template pack, fill in your company name, and move on. Do not. A policy is a control, and an auditor tests it the same way as any other control: does what the document says actually happen?

The classic failure is a policy that promises quarterly access reviews when the company has never done one. That gap is worse than having no policy at all, because now you are on record claiming a control you cannot evidence. Write policies that describe what you genuinely do, or change what you do to match the policy you need, and then keep the two in step. A short policy that is true beats a long one that is fiction.

Treat policies as living documents with an owner, a review date, and a version history. “Approved eighteen months ago, never looked at since” is a finding waiting to happen.

Step 5: Collect the evidence

Evidence is the currency of compliance. It is the proof that a control is not just written down but actually operating. When people describe becoming compliant as painful, this is almost always the part they mean, because evidence lives everywhere and belongs to everyone except the person assembling it.

Evidence comes in a few shapes:

• Documents: policies, procedures, risk assessments, meeting minutes, signed approvals.
• Configurations: a screenshot or export showing MFA enforced, encryption enabled, a firewall rule in place.
• Logs and records: access review outputs, backup success reports, training completion records.
• Tickets: the incident that was handled, the change that was approved, the vulnerability that was patched.

The hard part is that most of this evidence is not held by the compliance owner. The network configuration is with the infrastructure team, the HR records are with people operations, the access reviews are with whoever owns each system. Chasing it by email is where months disappear. The efficient pattern is to route each request to the person who actually holds the evidence, let them submit it directly, and have one reviewer approve it and close the control. That is exactly what delegated evidence collection is for.

Step 6: The audit, certification, or self-assessment

With controls in place and evidence collected, you reach the assessment. What happens here depends on which of the three proof types from earlier applies to you, but the rhythm is similar. An assessor, internal or external, works through the requirements, asks for evidence against each one, and samples: they will not check every access review from the year, they will pick three and expect them to hold up.

For a certification like ISO 27001, expect two stages. A first stage checks that your documentation and management system exist, and a second stage checks that they are operating with evidence. For an attestation like SOC 2, a Type I report looks at a single point in time, while a Type II report examines whether controls operated over a period, usually three to twelve months, which is why the evidence discipline from step five matters so much.

The way to not fail is unglamorous: do a readiness review first. Run your own gap analysis one more time, honestly, and close anything still open before the real assessor arrives. Auditors rarely fail organisations that have done the work and can find their evidence quickly. They lose patience with organisations that scramble.

Step 7: Stay compliant, because it is a loop and not a project

This is the step almost every first-timer underestimates. Passing an audit is not the finish line, because compliance decays. Evidence has a shelf life: an access review from fourteen months ago proves nothing about today. Certifications expire and demand surveillance audits along the way. Regulations change, and new ones arrive. The organisation that treated compliance as a one-time project finds itself doing the whole scramble again next year.

The organisations that make this sustainable stop treating evidence collection as an annual event and turn it into a background cadence. Each piece of evidence carries an expiry date. When it approaches, the request goes out again automatically, to the same owner, and the control quietly re-closes on approval. Done well, staying compliant becomes maintenance rather than a fire drill, and next year’s audit is a formality instead of a crisis.

How long does it take to become compliant?

The honest answer is that it depends on your starting point and scope, but ranges help. For a mid-size company approaching its first framework, a realistic first pass looks roughly like this.

• Gap analysis: one to two weeks to score yourself honestly across the framework.
• Remediation: two to six months, driven almost entirely by your heavy-lift gaps and how much competes for your team’s time.
• Evidence collection: starts in parallel with remediation and then never fully stops.
• Assessment: two to eight weeks for a certification audit, and for a SOC 2 Type II report add the observation window of three to twelve months on top.

If you are already reasonably mature and just need to formalise, the whole thing can be a couple of months. If you are starting from a blank page, plan for the better part of a year to a first certificate, and remember that the second framework is dramatically faster than the first because of the overlap we are about to discuss.

How much does it cost?

Compliance cost has three components, and the one people forget is the largest.

• Internal time. This is the big one, and it is invisible on any invoice. The hours your team spends on remediation and, above all, on chasing and assembling evidence dwarf the other costs. Anything that reduces this is where the real savings live.
• Auditor or assessor fees. A third-party certification or attestation is a real external cost that scales with your size and scope. Budget for it as a recurring expense, since certifications recur.
• Tooling. Software to run the gap analysis, track remediation, collect evidence, and keep it fresh. Good tooling earns its keep by cutting the internal-time component, which is why it usually pays for itself rather than adding to the bill. You can see how we price this on our pricing page.

The trap is to optimise the small, visible costs while ignoring the large, invisible one. A cheaper auditor saves a little once. Cutting the evidence-chasing burden saves a lot, every year.

The shortcut: prove once, satisfy many

Here is the payoff for the overlap we flagged back in step one. The frameworks and regulations you are subject to are not separate worlds. They ask for the same controls in different words. Access control, encryption, incident response, vulnerability management, supplier due diligence, and business continuity show up in nearly every framework. The evidence that proves multi-factor authentication for ISO 27001 is the same evidence that proves it for SOC 2, for DORA, and for NIS2.

If you manage each framework in its own spreadsheet, you collect that evidence again and again, once per framework, which is precisely why so many teams find compliance crushing. The alternative is a control crosswalk: map the equivalent controls across every framework once, and let a single piece of evidence satisfy all of its equivalents at the same time.

This is the difference between compliance that scales and compliance that does not. Prove a control once and watch it close across every framework it belongs to. It is also why your second framework is so much faster than your first: most of the work is already done, and you are only filling the genuinely new gaps. You can explore how the mapping works on our control crosswalk.

Common mistakes that slow you down

• Boiling the ocean. Trying to fix everything at once instead of ranking gaps by risk and effort. You run out of energy before you run out of gaps.
• Flattering the gap analysis. Scoring controls higher than the evidence supports. The truth surfaces later, in front of an auditor, at the worst time.
• Template policies nobody follows. Documents that describe an aspirational company rather than the real one. An unmet policy is a finding, not a control.
• Leaving evidence to the end. Treating collection as a last-minute sprint rather than a background habit. This is where months vanish.
• Managing each framework separately. Re-collecting the same evidence per framework instead of proving it once and crosswalking it.
• Declaring victory at the audit. Forgetting that evidence expires and certifications recur. Compliance is a loop.

Frequently asked questions

Which framework should I start with?

Start with whichever one a customer or regulator is actually asking for, because that is the one with a deadline attached. If nobody is forcing a specific one and you sell software, SOC 2 or ISO 27001 is the usual first step. Because of the crosswalk effect, the first framework is the expensive one, and everything after it rides on the same evidence.

Can I become compliant without a consultant?

Yes, especially for the first, framework-heavy standards, if you have someone who can own the programme and the right tooling to run the gap analysis and manage evidence. Consultants add the most value on genuinely complex regulatory regimes and on interpreting ambiguous requirements. They cannot manufacture your evidence for you, so the internal work remains either way.

Is a gap analysis the same as an audit?

No. A gap analysis is something you run on yourself to find weaknesses before anyone else does. An audit is a formal review carried out by an external party against a defined standard. The gap analysis is preparation, and the audit is the exam.

How do I keep from having to redo everything next year?

Turn evidence collection into a continuous cadence rather than an annual event. Give each piece of evidence an expiry date, re-request it automatically when it ages out, and keep your crosswalk current so new frameworks reuse what you already have. That converts next year’s audit from a scramble into a formality.

Where to start today

Becoming compliant is a process, not a leap. Work out what applies to you, score yourself honestly, fix the gaps that carry the most risk, write policies that are true, collect your evidence once and reuse it everywhere, pass the assessment, and then keep the loop turning. None of the individual steps are hard. The difficulty has always been the sheer volume of coordination, and that is exactly the part good tooling removes.

The fastest way to see where you stand is to run a gap report against the framework you care about. It takes about ten minutes and needs no commitment to get going. Start with a free compliance check, and see your real gaps before you decide what to do about them.

Primary sources

This guide is framework-agnostic, but the specific factual claims above trace to these standards and regulations. Verify current scope and deadlines against the primary text for your situation.

• ISO/IEC 27001:2022 - certification standard; the two-stage audit (Stage 1 readiness, Stage 2 effectiveness) and three-year cycle with annual surveillance are set by ISO/IEC 17021-1. iso.org.
• SOC 2 - AICPA attestation under the Trust Services Criteria; Type I is point-in-time, Type II covers an observation period (commonly three to twelve months). aicpa-cima.com.
• GDPR - Regulation (EU) 2016/679; Art 3 sets the territorial scope that reaches controllers offering goods or services to, or monitoring, people in the EU. EUR-Lex.
• DORA - Regulation (EU) 2022/2554; applies to financial entities and their ICT third parties, in force since 17 January 2025. EUR-Lex.
• NIS2 - Directive (EU) 2022/2555; covers essential and important entities. EUR-Lex.
• Cyber Resilience Act - Regulation (EU) 2024/2847; products with digital elements, core obligations from 11 December 2027 (reporting duties from 11 September 2026). EUR-Lex.
• PCI DSS - PCI Security Standards Council; lower merchant tiers may self-assess via an SAQ. pcisecuritystandards.org.
• HIPAA - US Department of Health and Human Services, Security and Privacy Rules. hhs.gov/hipaa.