What Is IT Compliance? Frameworks, Evidence and Who Owns It

Updated: October 2026

Sooner or later someone asks for proof that your company protects its data, and the question lands on whoever runs IT. It might be a client security questionnaire, an insurer's renewal form or an auditor with a deadline. This guide explains what IT compliance is, which rules and frameworks apply to you, who owns which part, and how to produce evidence without rebuilding it from scratch every year.

TL;DR

• IT compliance means meeting the outside requirements that apply to your technology and data, and being able to prove it.
• Requirements come from three places: laws (HIPAA, GDPR, the FTC Safeguards Rule), contracts (PCI DSS, CMMC, SOC 2 requests) and voluntary frameworks you choose as a spine (NIST CSF 2.0, CIS Controls, ISO 27001).
• The business owns the obligation. IT or the MSP runs the controls and produces the evidence. An auditor tests it, and never the person who built it.
• Evidence is the hard part. Capture it when the work happens, not when someone asks.
• Small companies can start with one register, one framework, one owner per control and an evidence calendar.

What Is IT Compliance?

IT compliance is the work of meeting the external requirements that apply to your systems and data, and showing that you meet them. The requirements come from laws, contracts and standards. The showing comes from evidence: records an outsider can check.

That makes it two jobs. Doing covers the controls themselves: MFA switched on, patches applied, backups tested. Proving covers the policies, reports, logs and sign-offs that show those controls ran during the period someone is asking about.

Compliance and security overlap, but they are not the same thing. Security is about lowering risk. Compliance is about meeting a defined bar and demonstrating it. A company can pass an audit and still get breached, and a well-run IT team can fail one because nobody kept the records.

Regulations, Contracts and Frameworks: Three Kinds of "Must"

Confusion usually starts with lumping every acronym into one pile. Sort them by where the obligation comes from, and the list gets shorter.

Regulations are laws with penalties. HIPAA covers healthcare providers and their business associates. GDPR covers personal data of people in the EU, with fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher, for the most serious infringements. The FTC Safeguards Rule covers non-bank financial institutions such as tax preparers, mortgage brokers and auto dealers, and since May 2024 it requires notifying the FTC within 30 days of a breach affecting at least 500 consumers. Our FTC Safeguards Rule checklist breaks that one down.

Contract requirements apply because a customer or partner says so. PCI DSS reaches you through card processing agreements. Version 4.0.1 was published in June 2024, and its future-dated requirements became mandatory on 31 March 2025. CMMC reaches you through Defense Department contracts, and Phase 1 self-assessments started on November 10, 2025. SOC 2 is not a law at all: it shows up because a customer asks for your report.

Frameworks are structures you choose. NIST released CSF 2.0 on February 26, 2024, with six functions: Govern, Identify, Protect, Detect, Respond and Recover. CIS Controls v8.1 is more prescriptive, and ISO/IEC 27001:2022 is the one you can certify against. A framework doesn't create an obligation by itself. It gives you one organised way to meet several.

For a longer comparison of the frameworks themselves, see our cybersecurity frameworks list.

This overview of the frameworks a GRC team deals with covers the same ground from the practitioner side.

Who Owns IT Compliance?

Ownership splits four ways, and trouble starts when one person quietly holds all four.

The business owns the obligation. Leadership decides which markets and customers to pursue, accepts the risks that come with them and signs the attestations. The compliance lead, often a part-time role in a small company, keeps the register of obligations, the control list and the evidence calendar.

IT or the MSP owns the controls and produces most of the evidence. That includes the MFA policy, the patch reports, the backup tests and the access review exports. The auditor or assessor tests all of it, and independence is the point. The person who built a control cannot be the person who signs off that it works.

In small companies, the IT person often absorbs the compliance role without ever being given it formally. This r/Compliance thread asks whether that pattern is unique to defense contractors. The replies suggest it's common anywhere below a certain size.

When an MSP runs the environment, write the split into the contract. Name who produces which evidence, in what format and how often. A client that assumes "the MSP handles compliance" and an MSP that assumes "we just run the tools" will both be surprised at audit time. The questions to ask an MSP before signing include this one.

Controls and Evidence: What "Proof" Looks Like

A control is a statement of what you do. "Multi-factor authentication is required for all remote access" is a control. Evidence is the artifact that shows the control ran during the period under review.

Evidence comes in a handful of forms:

• Policies and procedures, approved and dated, with an owner named.
• Configuration exports, such as a conditional access policy or a firewall rule set, pulled from the system itself.
• System reports, such as an MFA registration report, a patch compliance report or a backup job history.
• Tickets and sign-offs, such as a quarterly access review with the reviewer's approval recorded.
• Training and attestation records, showing who completed security awareness training and when.
• Screenshots, as a last resort, with the date, the system and enough context to show what they prove.

Good evidence is dated, attributable to a system or a person, complete for the whole scope, and repeatable. If you can't produce the same artifact next quarter by running the same steps, it won't hold up as evidence.

Take the MFA control. The evidence set might be the remote access policy, an export of the conditional access rule, a registration report showing every user enrolled, a sign-in log sample and a short list of approved exceptions with an expiry date. Five artifacts, all pulled from systems that already exist.

Finding the proof is usually the painful part. This r/Compliance post from a team that just passed SOC 2 says exactly that, and the replies land on the same fix: capture evidence when the work happens, and give each control domain one owner.

One Control, Many Requirements

The reason to pick a framework as a spine is reuse. The same control usually satisfies several obligations at once, so you build it once and file the evidence against each.

MFA is the clearest example. Here is how one control lines up across the requirements from the table above:

One conditional access policy, one registration report and one exception list answer all five. Without a mapping, teams collect the same screenshots five times in five formats. With one, the evidence folder has a single MFA section, and each requirement points to it.

The same logic applies to patching, backups, logging and access reviews. Those five controls between them cover a large part of what the requirements above ask for.

Answering Security Questionnaires

At a small company, the first compliance request often isn't an audit. It's a spreadsheet from a customer with a long list of questions about encryption, access control and incident response, due in two weeks.

Treat the first one as the start of a library. Answer each question once, precisely, and store the answer with the evidence that backs it. The next questionnaire will ask the same things in different words, and most of the work becomes matching.

Answer what is true today, not what the policy intends. "MFA is enforced for all remote access; exceptions are documented and expire after 30 days" is an answer a customer can trust. "We follow industry best practice" invites follow-up questions and weakens every other answer on the sheet.

When the true answer is "not yet", say so and add a date. A named gap with a remediation plan reads better than a vague yes that fails the first evidence request. Keep a short security overview document ready as well. Some customers accept it in place of a full questionnaire, and that saves both sides a week.

Point-in-Time vs Continuous Compliance

Traditional compliance runs on audit dates. You prepare, the auditor tests, you get a report, and attention drifts until the next cycle. SOC 2 shows the difference well. A Type I report checks that controls are designed properly on one date. A Type II report checks that they operated over a period of months.

The gap between audits is where things quietly break. A new admin account appears, a laptop drops out of patching, a backup job starts failing and nobody reads the alert. None of it shows up until the next evidence request.

Continuous compliance closes that gap. Automated checks read configuration state on a schedule, compare it with the control and flag drift at the next check. Evidence gets saved as a by-product of normal operations instead of reconstructed later. Our comparison of compliance automation software covers the tools built for this.

Automation handles the repeatable parts well: configuration checks, access lists, patch status and backup results. It doesn't write policies, run interviews or make risk decisions. Those stay with people. OpenFrame can run a configuration check as a script across a client's devices and collect the output, which turns a quarterly screenshot hunt into a saved report.

Common IT Compliance Gaps

Scope is the first gap. You can't prove controls on systems you don't know about. An asset inventory and a data map come before everything else, and they are often missing or stale.

Shared and forgotten accounts come next. Admin accounts shared between technicians, service accounts with passwords that never change, and accounts belonging to people who left months ago all fail an access review. Quarterly reviews exist to catch them, and they are easy to skip when the quarter gets busy.

Third parties are the gap that grows fastest. Every SaaS tool and service provider that touches your data extends your scope. Our guide to vendor risk management covers how to keep that list under control.

Paper controls are the quiet gap. A policy that says backups are tested quarterly, with no restore test on record, is a finding waiting to happen. Write down what you do, then do what you wrote, and keep the record.

Then there's evidence stored in inboxes. When proof lives in email threads and personal drives, it disappears when people leave. A shared evidence folder with a naming rule, or a compliance platform, fixes this for very little effort.

A Starter IT Compliance Roadmap for a Small Company

You don't need a compliance department to get this under control. You need a register, a spine and a calendar.

1. List your obligations. Write down every law, contract clause and customer requirement that applies, with the reason each one applies. This is your register.
2. Pick one framework as the spine. CIS Controls IG1 suits a small team that wants a concrete checklist. NIST CSF 2.0 suits reporting to leadership. Map each obligation to it so one control can satisfy several requirements.
3. Inventory systems and data. Know which devices, accounts, SaaS tools and data stores are in scope, and where regulated data lives.
4. Assign one owner per control. A named person, not a team. The owner runs the control and produces the evidence.
5. Set an evidence calendar. Monthly patch reports, quarterly access reviews, a yearly policy review and restore tests on a fixed schedule. Save every artifact to one place with dates in the file names.
6. Close the common gaps first. MFA everywhere, patching with reporting, tested backups and access reviews cover a large share of what auditors and insurers ask about.
7. Run an internal audit. Test your own controls against the register before anyone else does. Our upcoming guide to security audit procedures walks through the steps.
8. Decide on external proof. If customers keep asking, a SOC 2 report or ISO 27001 certification may pay for itself. Our look at SOC 2 for MSPs covers when it's worth it.

The Short Version

IT compliance is doing the controls your obligations require and keeping the proof. Sort requirements by where they come from, pick one framework to organise them, give every control a single owner and capture evidence as the work happens. The audit then becomes a matter of handing over files that already exist.

If defense contracts are on your roadmap, our CMMC compliance guide covers what the phased rollout means in practice.

For the governance layer above all of this, read our guide to building an IT governance framework.