Safeguard
Compliance•

What should a founder check in a compliance tool each month?

A non-technical founder can review compliance automation in 30 minutes a month with five questions: trend, age, owners, claims and connections.

Safeguard Security Team
8 min read

Each month, a founder should check five things in a compliance tool: whether failures are trending down, whether any failure is older than 30 days, whether every control has a named owner, whether public claims match the evidence, and whether connections are healthy. Thirty minutes is enough if you ask the same five questions every time.

TL;DR: You do not need to understand every test. You need to know whether the program is moving in the right direction, who is responsible for each part, and whether what you say to customers is true. Use the five questions below, write a three line note, and ask for help when an answer is "I do not know."

Definition box. A founder check is a short, regular review by the person who is accountable for the business, aimed at trend, ownership, and honesty of claims, not at technical detail.

Why should a founder look at this at all?

In a small company, the founder is often the person who signs contracts, answers customer questions, and is ultimately responsible if something goes wrong. Even if an engineer runs the tool day to day, the founder carries the risk of what the company says in public.

The Journal of Accountancy has reported that SOC practitioners worry about marketing that promises fast, easy results, and notes that "compliance" is a term never used in SOC 2 examinations. A founder who knows this will be careful about words on a website, in a sales deck, or in a reply to a customer. The monthly check is partly about protecting those words.

It is also about attention. Compliance work tends to fade when no senior person looks at it. A monthly check, even a short one, tells the team it matters.

What are the five questions?

#QuestionWhat a good answer looks like
1Is the number of failing tests going down, flat, or up?Down or flat, with reasons for any rise
2Is anything failing for more than 30 days?Few or none, and each has an owner and a date
3Does every control have one named owner?Yes, and each owner knows it
4Do our public claims match our evidence?Yes, checked this month
5Are all connections healthy and not about to expire?Yes, with expiry dates tracked

Ask them in this order. Each one takes three to six minutes.

How do you check each question?

1. Trend. Open the dashboard and look at the count of failing tests over time. You are looking at direction, not the exact number. A rise is not always bad. Adding a new system or a stricter test can cause one. Ask the owner for the reason. Do not accept "it fluctuates" as an answer without a cause.

2. Age. Ask for a list of failures older than 30 days. Old failures are the ones that quietly become audit findings. For each, ask three things: who owns it, what is blocking it, and when will it be fixed? If the answer is a date, good. If the answer is "we are looking at it," ask again next month.

3. Owners. Ask the person running the tool to show the list of controls with owners. Look for blanks, for former employees, and for one person owning too many. A control with no owner has no one who will fix it. Our control owner assignment checklist helps you set this up.

4. Claims. Open your website, your trust page, your latest sales deck, and your most recent questionnaire answers. Read any sentence about security. For each claim ask: where is the evidence? If no one can show it quickly, change the claim or add the evidence. Be especially careful with words that claim a result you may not hold, such as approved, passed, or fully secure. Our post on which word is true when you describe your audit status gives safe wording. The guide on what a passing test proves explains why a green dashboard is not a claim you can make.

5. Connections. Ask whether any connection is in an error state or expires within 60 days. A broken connection leaves a gap in your records. See what to do when an evidence connection breaks.

How do you write the three line note?

After the check, write three lines and save them in your evidence folder with the date.

  1. Trend: up, flat, or down, and the reason.
  2. Concerns: items over 30 days, missing owners, or claims to change.
  3. Decisions: what you asked for, from whom, by when.

These notes have a second use. They show that leadership reviews the program on a regular schedule. Ask your auditor how they would use that information, and do not describe it as a requirement of any framework unless they confirm it.

A worked example with invented numbers

The numbers below are invented for illustration.

The founder of a twelve person company sits down on the first Monday of the month with the head of engineering. They spend 30 minutes.

  1. Trend. Failing tests: 14 last month, 11 this month. Down. The head of engineering says three were fixed and one new one appeared when a new repository was created without a review rule.
  2. Age. Two failures are older than 30 days. One is about laptop encryption on two older machines, with an owner and a replacement date in three weeks. The other has no owner. The founder asks the head of engineering to take it, with a date.
  3. Owners. Of 38 controls, 36 have owners. Two belong to someone who left in August. They are reassigned during the meeting.
  4. Claims. The founder finds a sentence on the website that claims full adherence to industry standards. Nobody can point to evidence for that. The sentence is replaced with "We run automated checks on our security controls and are preparing for an independent SOC 2 examination." The new sentence is true as long as the preparation is real, and the founder asks the team to confirm.
  5. Connections. One connection token expires in 40 days. A task is created to renew it in 25.

The note reads: "Trend down 14 to 11. Two items over 30 days, one reassigned. Two controls reassigned. Website claim corrected. Token renewal scheduled." Total time: 30 minutes. Result: four concrete fixes, including one change that prevents a future overclaim.

What should a founder not do?

  • Do not ask for the screen to be all green. Pressure for green can push people toward exceptions and edits that hide problems.
  • Do not skip months. The value is in the rhythm.
  • Do not make promises to customers based on a dashboard color. Ask the owner and, if needed, your auditor what you can say.
  • Do not ask engineers to do this check for you. You can have them present, but you should look at the screens yourself.

What if I do not understand an answer?

Say so. "Explain that in plain words" is a good phrase. If the owner cannot explain it simply, that is information. Good owners can explain their controls in a sentence or two. If they cannot, ask for a short note on how the control works and where the evidence lives. That note is useful for the team and for an auditor.

For a quick way to share the program with others, see how to explain compliance evidence automation in one page.

Where does Safeguard fit?

Safeguard offers compliance and evidence automation with dated results, which makes the monthly trend and age questions easy to answer. Its policies, gates, and dependency scanning cover the software side. It does not replace an independent auditor, and it does not decide what you can say publicly. You can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Click through the demo to see how controls connect to framework questions. When you review owners each month, this is the map of what each owner is responsible for.

Quick check

Is thirty minutes really enough?

For a small company in steady state, yes. In the first few months you may need longer while gaps are being fixed. Keep the same five questions.

Should the founder have tool access?

Read access to the dashboard is usually enough. Keep admin rights with the people who run the program, and review who has access as part of your normal access review.

What if the trend is rising and nobody knows why?

Ask the owner to group the new failures by cause. A rise from a new system is normal. A rise with no cause is worth a short investigation using the steps in the triage guide.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.