In compliance automation, a control is a rule your team follows, a test is an automatic check that the rule is being followed, and evidence is the dated record the test keeps. The audit period is the window of time those records must cover. A framework is the list of rules a buyer or auditor asks about.
TL;DR: Five words explain almost every compliance dashboard: control, test, evidence, audit period, and framework. Learn them once and the screens stop being confusing. This guide defines each one in plain language, shows how they fit together with an invented example, and gives you a short script for explaining them to a teammate.
Definition box. Evidence is a record that shows a control actually ran, with a date, a source, and enough detail that someone who was not there can check it. A screenshot with no date is weak evidence. A system export with a timestamp is stronger.
Why do compliance tools use so many unfamiliar words?
Compliance work grew up in the world of auditors, and auditors have their own vocabulary. Compliance software borrowed that vocabulary and added some of its own. If you are a founder, an engineer, or an office manager who was handed this job, the screens can feel like a foreign language.
The good news is that the ideas are simple. They are the same ideas you use when you run a kitchen or a workshop. You have a rule (wash hands before cooking). You have a way to check the rule (a checklist signed each shift). You keep the checklists. Someone inspects them later.
Here is the same idea in compliance words:
| Everyday idea | Compliance word |
|---|---|
| The rule you follow | Control |
| The check that the rule was followed | Test |
| The signed checklist you keep | Evidence |
| The stretch of time an inspector looks at | Audit period |
| The inspector's list of rules | Framework |
Keep this table in mind. The rest of this guide fills in the details.
What is a control?
A control is a specific thing your company does, on purpose, to reduce a risk. It is written as a statement you can check. "We require a second person to review code before it goes live" is a control. "We take security seriously" is not, because nobody can check it.
Good controls share three traits. They are specific, so two people would agree on whether they were followed. They have an owner, a named person who answers for them. And they have a rhythm, such as "every change," "every quarter," or "within one day of someone leaving."
You will also hear the word policy. A policy is the written promise at the top, such as "Access to customer data is limited to people who need it." A control is the concrete action that carries the policy out, such as "We review who has access to the production database each quarter." If you want a deeper look at the difference, see control objective, control activity, policy, and procedure.
What is a test in a compliance tool?
A test is an automatic check that asks, "Is this control working right now?" The tool connects to one of your systems, reads some settings or records, and reports pass or fail.
For example, a test might look at your code host and ask whether the main branch requires a pull request before changes are merged. GitHub documents this kind of setting as branch protection, where rules can control whether people can delete or force push to a branch and can require checks to pass before merging. A tool can read that setting and tell you whether it is on.
Two things are worth knowing about tests.
First, a test looks at a setting or a record. It does not look at your intent. A pass means the system matched the check on the day it ran. It does not prove that every person followed the rule every day. We cover that gap in what a passing compliance test proves.
Second, tests run on a schedule. A single pass on Monday says little about Friday. Running tests again and again, and keeping every result, is what turns a one-time check into a history. That idea is sometimes called continuous compliance monitoring.
What counts as evidence?
Evidence is what is left behind when a control runs. Strong evidence has four parts: what happened, when it happened, which system recorded it, and who was involved.
Common examples include:
- An export from your code host showing each merged change and who approved it.
- A list of accounts in your identity system with the date each one was last used.
- A signed policy with the names of people who acknowledged it and the dates.
- A ticket showing a vulnerability was found, assigned, and fixed.
Evidence made by a system on its own is usually easier to trust than evidence a person assembled by hand, because it is harder to edit after the fact. A date stamped by the system carries more weight than a date typed into a spreadsheet. For more on this, see how fresh compliance evidence has to be.
Some evidence will always need a person, such as a manager's decision to accept a risk. We list those cases in which compliance evidence cannot be automated.
What is an audit period?
An audit period is the window of time an auditor examines. A report might cover the six months from January through June, for instance. During that window, your controls need to have run, and you need records to show it.
This is why starting early matters. If your first test passes in month five of a six month window, you have one month of history, not six. The Journal of Accountancy describes SOC 2 reports as covering controls relevant to security, availability, or processing integrity, plus the confidentiality and privacy of the information a system handles. Which of those your report covers, and for what period, is decided between you and your auditor, not by a software tool.
What is a framework, and why do tools map controls to several?
A framework is a published list of expectations that a buyer, regulator, or auditor uses to judge you. SOC 2, ISO 27001, and HIPAA are well known examples. Each one asks for its own set of things, but many of the asks overlap.
For example, "limit who can reach customer data" shows up in many frameworks in different words. Compliance tools take advantage of that. You write one control, run one test, keep one piece of evidence, and the tool links it to every framework question it helps answer. This is called mapping. You will see it in the demo below.
One caution on wording. In an article on SOC reporting, the Journal of Accountancy notes that "compliance" is a term never used in SOC 2 examinations. Auditors give an opinion on controls. So do not tell customers you have a SOC 2 result because a dashboard turned green. Say what is true: which controls you run, and whether an independent audit is planned, underway, or finished. See which word is true when you describe your audit status.
A worked example with invented numbers
The numbers below are made up to show how the pieces connect. They are not from a real company.
A twelve person software company writes this control: "Every change to production code is reviewed and approved by someone other than the author before it is merged."
- Owner: The head of engineering.
- Test: Each night, the tool reads the code host and checks that the main branch requires one approving review.
- Evidence: The nightly result, plus a monthly export of merged changes with the approver's name and time.
- Audit period: January 1 to June 30.
At the end of June, the export shows 140 merged changes. Of those, 138 had an approval from a second person. Two were urgent fixes merged by one person during an outage, and each has a ticket explaining why, plus a review the next morning.
The auditor can now see the rule, the nightly checks across six months, the full list of changes, and a clear explanation for the two exceptions. That is a complete story. The tool did the collecting. A human wrote the explanation.
How do you explain this to a teammate in five minutes?
Use this short script.
- Start with a rule. Pick one thing your team already does, like requiring a review before release.
- Name it a control. Say, "This is a control. We wrote it down and someone owns it."
- Show the check. Open the dashboard and point to the test that watches it.
- Show the record. Click into the results and show the dated history. Say, "This is the evidence."
- Show the window. Point out the date range. Say, "An auditor looks at this window, so gaps in it matter."
- Show the mapping. Open the framework view and show that one control answers several questions.
Most people grasp the whole system after that walkthrough.
Where does Safeguard fit?
Safeguard offers compliance and evidence automation that helps teams collect, organize, and keep evidence current, along with dependency scanning and SBOM (software bill of materials, a list of the parts inside your software) features that produce records for the software side of your controls. Safeguard does not issue audit opinions. Your independent auditor does that. You can also run a free scan of your own code at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the demo and watch how a single control connects to questions in more than one framework. Look for the link between a control and the evidence behind it.
Quick check
Is a control the same as a policy?
No. A policy is the written promise, such as "access to customer data is limited." A control is the specific action that carries it out, such as a quarterly access review. A policy without controls is only words.
Can one piece of evidence support more than one framework?
Often yes. If a record shows who approved each code change, it may help answer questions in several frameworks. Your tool or your auditor decides which questions it answers.
Does a green dashboard mean we have passed an audit?
No. A dashboard shows that automatic checks passed. An independent auditor decides what a report says. Describe your controls and audit status honestly instead of using a label.
Sources
- Promises of fast and easy threaten SOC credibility, Journal of Accountancy
- System and Organization Controls: SOC Suite of Services, AICPA and CIMA
- About protected branches, GitHub Docs
Last reviewed: 19 October 2026.
