Checks + Registers → Evidence Reports: A Simple Governance Model for Lean IT Teams

Checks + Registers → Evidence Reports is a three-layer model for IT governance in small teams: automated checks verify what is publicly observable, human-maintained registers record what only your team knows, and generated evidence reports turn both into dated, management-ready artifacts. One person can run the whole model in a few hours a month, and its output is exactly what leadership, customers, and insurers ask for when they want proof that IT is under control.

This article explains each layer, why the split between machine-verifiable and human-known information matters, and what a realistic monthly routine looks like. For the underlying definition of evidence itself, start with What Is IT Governance Evidence?

The Model in One Sentence

Machines verify public signals (checks), people maintain structured records of what machines cannot see (registers), and both flow into dated point-in-time documents (evidence reports) that anyone outside IT can read.

The arrow in the name matters: checks and registers are inputs, the report is the output. Most governance efforts in small companies fail at the arrow — information exists in monitoring tools and spreadsheets, but nothing ever becomes an artifact you could hand to a manager. The model exists to force that last step.

Layer 1 — Checks: What Machines Can Verify From Public Signals

A check is an automated, scheduled verification of a publicly observable fact about your IT estate. The public footprint of any organization is larger than most people expect:

• SSL/TLS certificates — expiry dates, chain validity, and configuration are visible to anyone who connects.
• DNS records — A, AAAA, MX, NS, TXT, and CAA records are public by design; unexpected changes are detectable.
• Domain registration — expiry and status are queryable through RDAP, the structured successor to WHOIS.
• Email authentication — SPF, DMARC, MTA-STS, TLS-RPT, and BIMI records are published in public DNS precisely so others can read them.

Why public signals first

Public signals make the strongest first layer for three reasons. First, they are machine-verifiable: a check result is a fact read at a timestamp, with no human judgement to dispute. Second, they cover real, common failure modes: expired certificates, lapsed domains, and broken DMARC records are among the most visible IT failures a company can have. Third, they are privacy-clean: everything in this layer can be verified with zero access to internal systems, mailboxes, or devices — which means the governance routine starts without a security review, a vendor risk assessment, or an uncomfortable conversation about monitoring.

What public signals cannot tell you is everything else: who owns a system, when a contract renews, whether departed employees still have accounts. That is the second layer's job.

Layer 2 — Registers: What Only Humans Know

A register is a structured, owned, dated record of organizational knowledge that no scanner can discover. The four registers that cover most of a small company's governance surface:

• Renewals and vendors — what is subscribed to, what it costs, when it renews, who owns it.
• People and accounts — who works here and which systems each person has an account on.
• Assets — the hardware and software the company actually possesses.
• Access reviews — the periodic, recorded confirmation that the people-and-accounts picture is still correct, with revocations noted.

Why CSV-friendly manual registers beat broken automation

It is tempting to want this layer automated — directory sync, SaaS discovery, an agent on every laptop. For a 50–500-employee company the manual-first register is usually the better tool, for unglamorous reasons:

• Accuracy. Automated discovery produces noise that someone must triage; a register an owner maintains reflects deliberate knowledge, not inferred guesses.
• Ownership. A register entry has a name on it. "The sync said so" has no name on it.
• Privacy. Maintaining a register requires no credentials into anything, no agents, and no monitoring of anyone.
• Continuity. Your existing spreadsheets are not thrown away — a CSV-friendly register imports them, adds dating and structure, and exports back out. The spreadsheet knowledge survives; the spreadsheet chaos does not.

The honest cost is upkeep: a register is only evidence if it is reviewed on a cadence. That cost is real but small — and it is the same work a security questionnaire forces you to do anyway, done once and kept.

Layer 3 — Evidence Reports: Turning Both Into a Dated Artifact

An evidence report is a generated, self-contained, dated document that captures the state of your checks and registers at one moment. It is the only layer outsiders ever see, and it has properties neither input layer has on its own: it is fixed in time, scoped to what it covers, readable without logging into anything, and comparable month over month.

This layer is where most home-grown governance breaks down. Monitoring tools alert; spreadsheets accumulate; but unless something regularly renders the current state into an artifact, there is nothing to hand over when the question comes. The report is the deliverable — the evidence reports module page describes the report types CertPilot generates, and the sample reports gallery shows fully rendered examples.

Running the Model: A Monthly Routine for One Person

A realistic month under the model, for one IT manager:

1. Daily (zero effort): checks run automatically against the public footprint — certificates, DNS, domain status, email-authentication records. You only hear about problems.
2. Monthly (~1–2 hours): review the registers. Add new vendors and people, mark departures, update renewal dates that changed. The CSV import handles the initial load; monthly upkeep is incremental.
3. Quarterly (~1 hour): run an access review — confirm, per system, who should still have access, and record completions and revocations in the register.
4. Monthly (~15 minutes): generate the evidence report, skim it, and send it to whoever asked — or file it, dated, for the next time someone asks.

The output compounds: after six months you have six dated, comparable artifacts demonstrating a routine, which is more persuasive than any single document.

Where the Model Intentionally Stops

The model is deliberately narrow, and the boundaries are features:

• It does not look inside systems. No mailbox scanning, no document access, no endpoint agents — internal truth enters only through a register, on a human's authority.
• It does not monitor people. There is no activity tracking and no productivity measurement anywhere in the model.
• It does not certify anything. The output is operational evidence that supports compliance and assurance conversations; it is not a certification, an audit, or legal advice.
• It does not replace your security stack. Checks read public signals; they are not a vulnerability scan or an intrusion-detection system.

A quick summary of the two input layers:

| | Checks | Registers | |---|---|---| | Source | Public signals (DNS, RDAP, certificates, email-auth records) | Your team's knowledge | | Automation | Fully automated, scheduled | Customer-maintained, manual-first, CSV-friendly | | Owner | The machine, with a timestamp | A named person, with a date | | Failure mode | Signal changes unnoticed → check catches it | Register goes stale → review cadence catches it |

What CertPilot Does — and Does Not Do — Here

CertPilot is a direct implementation of this model. Checks run automatically against public signals only — SSL, DNS, domain registration via RDAP, and email-authentication records (external footprint monitoring covers the details, and the methodology page documents exactly what is read). Registers for renewals, people and accounts, assets, and access reviews are maintained by you, with CSV import and export. Evidence reports are generated on demand. Nothing scans your inboxes, documents, or devices; nothing syncs from directories; nothing monitors employees. The platform overview shows all live modules.

In Short

• The model has three layers: checks (machines verify public signals), registers (humans record what machines cannot see), and evidence reports (both rendered into dated artifacts).
• Public signals come first because they are machine-verifiable, cover common real failures, and require no internal access.
• Registers are manual-first by design: accuracy, ownership, and privacy beat noisy automation at this company size.
• The report is the point — information that never becomes a dated artifact is not evidence.
• One person can run the full model in a few hours a month, and the dated artifacts compound into a track record.

Frequently Asked Questions

Do I need all three layers?

To produce evidence, yes — but you do not need them all on day one. Checks alone already produce real evidence about your public footprint. Add one register when ready (renewals are the usual first), and generate a report from whatever exists. The model degrades gracefully; it just gets stronger with each layer.

Can I run this model in spreadsheets?

Partially. Spreadsheets can hold register data, and many teams start there — which is why CSV import matters. What spreadsheets cannot do is the other two layers: they cannot run scheduled checks against public signals, and they do not render dated, self-contained reports. Spreadsheets are an input to the model, not an implementation of it.

How often should checks run versus registers be reviewed?

Checks should run at least daily — public signals like certificate status can change any day, and the cost of checking is zero once automated. Registers need a human cadence: monthly upkeep for renewals, people, and assets works for most teams, with access reviews quarterly. The report cadence is usually monthly, matching when someone might ask.

What goes in a register versus a check?

Apply one test: is the fact publicly observable? Certificate expiry, DNS records, domain status, and SPF/DMARC records are public — check them automatically. Contract renewal dates, system owners, employee accounts, and hardware inventories exist only in your organization's knowledge — register them. No fact should be maintained by hand if a machine can verify it, and no fact should be guessed by a machine if only a human knows it.

How long does the monthly routine take?

After initial setup, plan for roughly two to three hours a month: one to two hours of register upkeep, fifteen minutes to generate and skim the report, plus a quarterly hour for the access review. The initial register load takes longer — typically an afternoon per register if your existing spreadsheets are importable via CSV.