Checks + Registers → Evidence Reports is a simple operating model for lean IT governance. Checks verify what machines can read, especially public signals. Registers capture what only the team knows, such as owners, renewals, assets, people, accounts, systems, and review decisions. Evidence reports turn both into dated artifacts that leadership, clients, insurers, or audit-adjacent reviewers can understand. The arrow is the point: operational data becomes evidence only when it is packaged into a scoped report.
Jordan does not need an enterprise framework to understand the problem. The company already has monitoring outputs, vendor spreadsheets, account lists, asset sheets, access review notes, and screenshots. But when leadership asks, “What can we show?” the material is scattered. Checks are in one place. Registers are in another. The story is in Jordan’s head. The model gives Jordan a monthly path from operational truth to management-ready proof.
The model works because it separates two kinds of facts: facts a machine can verify and facts a person must maintain. Mixing those is how small-team governance becomes either over-automated fantasy or manual chaos. Let machines check public facts. Let humans own internal facts. Then create a dated report that explains both and says what remains unresolved.
For the definition of the evidence itself, start with what is IT governance evidence. For the software category that implements the model, read IT governance evidence platforms. To see the report layer directly, review the Evidence Reports module and the sample reports gallery.
The model in one sentence
Machines verify public signals, people maintain structured internal records, and the current state becomes a dated report with scope, findings, owners, and limitations.
That sentence is intentionally plain. A lean team needs a routine it can run, not a control library nobody can maintain. The model is not a replacement for formal compliance programs. It is a way to make recurring IT evidence visible before the company has a compliance department. If the next debate is whether this is “GRC” at all, use IT governance without enterprise GRC to frame the lighter evidence-layer path before a full compliance program exists.
Layer 1: Checks
Checks are facts a machine can verify on a schedule. Public-signal checks are the cleanest first layer because they do not require internal credentials or private data access.
Typical public-signal checks include SSL/TLS certificate status, DNS records, RDAP/domain registration data, public email-authentication records, and official public vendor-status feeds where supported. A check produces a timestamped observation: this record existed, this certificate expires on that date, this DNS value changed, this vendor status feed reported this state.
The strength of checks is repeatability. Once configured, they can run daily. They reduce dependence on memory. They also create evidence without reading inboxes, documents, device telemetry, or employee activity.
The weakness of checks is scope. A public check cannot know who owns a vendor, why a domain exists, whether a laptop was returned, which person holds a SaaS account, or whether an access review was completed. That is not a failure of checks. It is the boundary that makes the second layer necessary.
Layer 2: Registers
Registers are structured records maintained by the team. They hold facts that machines cannot reliably infer.
A small IT governance routine usually needs registers for renewals and vendors, people and accounts, assets, systems, and access reviews. Each register should have a named owner, a review cadence, status fields, dates, and enough context to be useful outside the person who created it.
The phrase customer-maintained matters. A register is not SaaS discovery running on its own. It is not directory sync. It is not endpoint inventory. It is a deliberate record of what the team knows and has reviewed.
The strongest register fields are boring: owner, status, date, scope, notes, and last-reviewed. Boring fields make evidence possible. A row without an owner is a risk. A row without a date is a guess. A row with an unclear status is not ready for review.
Layer 3: Evidence reports
Evidence reports are the output. They convert checks and registers into a fixed point-in-time artifact. The report should be readable by someone who does not operate the systems: founder, CFO, board member, customer, insurer, auditor, or MSP client.
A good report states what was checked, what was recorded, what was reviewed, which items need action, who owns follow-up, when it was generated, and what it does not claim. It is different from a dashboard because it is fixed in time. It is different from a spreadsheet because it packages the evidence and scope. It is different from an audit because it does not certify anything.
The Evidence Reports module page shows the report surface, and the sample reports gallery shows fictional examples of the output. For a small worked example of the same separation applied to one month of supplied figures — what was supplied, what was calculated, what is missing, what was decided — see the Copilot cost report template.
Why the arrow matters
The model is not “checks plus registers.” It is “checks plus registers become evidence reports.” Without the arrow, the first two layers create more data but not more trust.
A monitoring tool that never becomes a report still leaves Jordan explaining screenshots. A register that never gets reviewed becomes another spreadsheet. A completed access review that never becomes a dated artifact is hard to reuse. The arrow forces the governance routine to end in something shareable.
This is why reports should not be treated as decoration. The report is the deliverable. It is the artifact that lets a stakeholder see scope, facts, limits, and follow-up without asking Jordan to narrate the whole estate.
What belongs in checks versus registers
Use one test: can the fact be verified from a reliable source without internal judgment?
If yes, it probably belongs in checks. Certificate expiry, DNS records, RDAP/domain status, public email-authentication records, and official public vendor status are examples. A machine can read them, timestamp them, and repeat the result.
If no, it probably belongs in a register. Vendor owner, renewal decision, contract notice date, asset owner, laptop location, account owner, leaver status, system business owner, and access review decision all depend on human knowledge. Guessing those from logs or traffic can create more noise than clarity.
The clean split prevents two common mistakes. The first is maintaining by hand what a machine can verify. The second is pretending a machine can infer facts only a responsible person knows.
The monthly operating routine
A lean routine can be simple.
Daily: public checks run automatically. Jordan does not manually inspect every certificate, DNS record, domain status, email-authentication record, or vendor-status feed. Exceptions become review items.
Weekly or monthly: Jordan reviews register gaps. Missing owner, missing date, missing status, stale review, undecided renewal, unassigned asset, unknown account, overdue access review. The work queue comes from gaps in the record, not from vague anxiety.
Quarterly: Jordan runs access reviews for the systems in scope. Managers and system owners confirm what should stay, what should change, and what needs follow-up. Completed reviews create dated records.
Monthly: Jordan generates an evidence report, skims it, writes a short summary, and files or shares it. The report states the current state and limitations.
This routine compounds. One month gives a snapshot. Six months gives a track record. That track record is what stakeholders trust.
Example: access review evidence
For access reviews, public checks cannot tell the whole story. They may show public email-authentication records or domain signals, but they do not know whether Priya should still have admin access to payroll.
The register layer holds people, systems, accounts, owners, and statuses. The review layer records decisions. The report layer shows completed-review evidence, action-required counts, and next due date.
That is the model applied to user access: customer-maintained records become a review, and the review becomes an artifact. Related workflows include how a People & Accounts register supports access reviews, how to run a quarterly access review, and show management that user access is under control.
Example: asset evidence
For assets, a machine may not know whether a monitor moved from the London office to a remote employee, whether a spare laptop was retired, or who owns a software license. That is register work.
The Assets Register records hardware, software, owner, location, status, purchase context, and evidence gaps. The report does not need to expose serial numbers or license references to leadership. It can summarize total records, statuses, and missing fields. The detailed operational record stays in the register.
This is why the asset model begins with what an IT assets register is and IT asset register vs ITAM. Asset evidence is not the same as endpoint management.
Example: renewal and vendor evidence
Renewal records are mostly human-known. A public check might show a domain expiry date when RDAP exposes it, but contract notice dates, business owner, decision status, auto-renew risk, and renewal rationale live in the team’s knowledge.
The register records the vendor and renewal facts. The report turns upcoming, overdue, incomplete, and owner-missing records into a management view. That view is much stronger than a spreadsheet tab with no review date.
What the model intentionally does not do
The model does not look inside inboxes, documents, chats, AI prompts, or personal activity. It does not monitor employees. It does not automatically discover every SaaS account. It does not sync directories unless a specific connector is live. It does not remove access. It does not certify compliance, provide legal advice, or guarantee an audit result. It does not replace security tools, HR systems, MDM, ITAM, or enterprise GRC.
Those boundaries are part of the trust model. A report that clearly says what it does not prove is easier to trust than one that implies total control.
How CertPilot implements the model today
CertPilot’s platform follows this model. Public checks cover External Footprint Monitoring where supported: SSL, DNS, RDAP/domain status, email-authentication records, and public vendor-status signals. Customer-maintained registers cover renewals/vendors, People & Accounts, Assets Register, Systems Catalog, and Access Reviews. Evidence Reports generate Domain Health, Renewal Risk, Monthly Proof, on-demand Weekly Governance, Access Review Register, and Governance Evidence Pack reports.
People & Accounts and Assets Register are live dashboard registers, but dedicated People or Assets PDF reports are not built today. In the Governance Evidence Pack, those modules appear as summary counts where specified. Weekly Governance is on-demand only. Current registers are manual-first and CSV-friendly; they do not sync Google Workspace, Microsoft 365, HR systems, or identity providers today.
A first 30-day implementation plan
Week one: choose the first evidence question. Do not boil the ocean. Pick one leadership or customer request, such as “show renewal risk,” “show access review status,” or “show asset ownership gaps.”
Week two: identify the checks and registers needed for that request. Separate public facts from human-maintained facts. Do not ask a spreadsheet to behave like a monitor, and do not ask a monitor to know who owns an account.
Week three: clean the register fields that matter. Owner, status, date, scope, and notes beat thirty optional columns.
Week four: generate the report and write the limitations. Say what is covered, what is excluded, what needs follow-up, and who owns the next action.
Then repeat. The second report is easier than the first because the records already exist.
Cadence map for each layer
The model becomes much easier when each layer has its own cadence.
Checks should run most often because they are cheap once configured. Daily is a reasonable baseline for public signals such as certificates, DNS, domain status, email-authentication records, and vendor-status feeds. The team should not manually re-check those facts unless an exception needs investigation.
Registers should be reviewed on the cadence at which the human truth changes. Renewals may need monthly upkeep because notice deadlines and owner decisions drift. People and accounts should update during onboarding, role change, and offboarding, with a monthly cleanup pass. Assets should update when equipment moves, is purchased, returned, repaired, lost, or retired. Access reviews usually run monthly for high-risk systems or quarterly for the broader estate.
Reports should match the stakeholder rhythm. Monthly works for management proof. Quarterly works for access governance. Ad hoc reports work for customer, insurance, or audit-adjacent requests. The key is not the exact frequency; it is that the report date, source, scope, and limitations are visible.
When all three cadences are clear, Jordan no longer has to ask “what should I check this week?” The routine tells the team: machines watch public facts, owners maintain registers, and reports turn current state into evidence.
Source-of-truth rules for the model
The model only works if each fact has a clear home.
A certificate expiry date should come from a check, not a hand-maintained spreadsheet. A vendor business owner should come from the renewal register, not a monitoring dashboard. A laptop custodian should come from the asset register, not the HRIS. A person’s employment status may start from HR, but the account disposition belongs in People & Accounts and the access review. A completed review belongs in the completion log, not only in meeting notes.
This prevents double maintenance. It also prevents argument in the report review. If a fact is wrong, Jordan knows where to fix it. If a field is blank, Jordan knows which owner must supply it. If a stakeholder asks where a number came from, the answer is not “a spreadsheet somewhere.” It is the named check, register, or completed review.
What a first report should say
The first report does not have to be complete to be useful. It should say what was checked, which registers were included, which records are incomplete, which actions have owners, and what is outside scope. That honesty is the point.
For example, a first Governance Evidence Pack might say that public domain and email-authentication checks are included, renewals are imported from a CSV, access reviews cover only finance and production systems, and assets are summary counts only. It might also say that service accounts and vendor portals are a follow-up scope item.
That is a stronger artifact than a vague “all good” dashboard. It gives management something to trust and Jordan a work queue for the next cycle.
In short
- Checks verify public or machine-readable facts.
- Registers record human-owned facts and review context.
- Evidence reports turn both into dated, shareable artifacts.
- The arrow matters: data that never becomes a report rarely becomes trust.
- The model is manual-first where humans know the truth and automated where machines can verify it.
- CertPilot implements this model with public-signal checks, customer-maintained registers, and six on-demand report types.
Frequently Asked Questions
Do I need all three layers?
To produce strong evidence, yes. You can start with one check or one register, but the value compounds when current checks and maintained records become a dated report. Without the report layer, you still have to explain everything manually.
Can I run this model in spreadsheets?
Partially. Spreadsheets can hold register data, and CSV import/export keeps them useful. But spreadsheets do not run scheduled public checks or generate scoped evidence reports by themselves. They are inputs, not the full model.
How often should checks run versus registers be reviewed?
Public checks should run daily where possible because they are low-effort once configured. Registers need a human cadence: monthly upkeep for renewals, people, and assets, with access reviews often quarterly. Reports usually follow the management or client reporting cadence.
What goes in a register versus a check?
If a fact is publicly observable and machine-verifiable, check it. If it depends on internal ownership, business context, review judgment, or customer-maintained knowledge, register it. Do not manually maintain what a machine can verify, and do not ask a machine to guess what only a human knows.
Does this model certify compliance?
No. It produces operational governance evidence. That evidence can support management, client, insurance, or audit-preparation conversations, but it is not certification, legal advice, or a guaranteed audit result.