Public Signals vs Internal Registers: What Each Can Prove in IT Governance

Public signals and internal registers prove different things in IT governance. Public signals can prove externally visible facts such as SSL expiry, DNS records, RDAP/domain status, and email-authentication records. Internal registers can prove customer-maintained facts such as renewal ownership, people and accounts, assets, and access review completion.

The distinction matters because no single source can prove everything. Public data cannot tell you who owns a SaaS renewal, and a register cannot independently verify a public DMARC record. A useful evidence routine keeps the sources separate, uses each for what it can prove, and avoids turning governance evidence into content scanning, employee surveillance, productivity scoring, endpoint monitoring, or MDM.

Two Sources of Evidence, Defined

A public-signal check is an automated verification of a fact that is intentionally visible from outside the organization: DNS records, RDAP/domain registration data, TLS certificate details, public email-authentication records, and selected HTTP response headers.

An internal register is a customer-maintained record of facts that are not publicly knowable: who owns a vendor, when a SaaS subscription renews, which people have accounts, what assets exist, and when access was last reviewed.

The first source answers: "what can an outside party observe right now?" The second source answers: "what does the organization know, own, and maintain?" This article stands on its own; the broader operating framework is covered separately in Checks + Registers → Evidence Reports.

Public-Signal Checks

Public-signal checks are useful because they are repeatable, timestamped, and narrow. A machine can read the same public record every day without asking for a password, installing an agent, or touching private data.

What's publicly observable

In CertPilot, the public-signal layer includes:

• SSL/TLS certificate data: expiry date, issuer, chain context, and validity from the public TLS handshake.
• DNS records: A, AAAA, MX, NS, TXT, and CAA records, plus drift between public snapshots.
• Domain expiry/RDAP data: registrar and expiry information where the registry or registrar exposes it. IANA maintains the public RDAP bootstrap registry for domain name space, and RDAP itself is standardized through the RFC series.
• Email-authentication records: MX, SPF, DMARC, MTA-STS, TLS-RPT, and BIMI records published in DNS. SPF is defined in RFC 7208, DMARC in the RFC series including RFC 7489, and MTA-STS in RFC 8461.
• Selected public headers and files where relevant to trust-signal checks.

The CertPilot methodology is the product reference for current public data sources and limitations.

Why public signals are trustworthy evidence

Public signals make strong evidence for three reasons.

First, they are externally observable. If a certificate expires, a DNS record changes, or a DMARC record is missing, the fact does not depend on someone's opinion. It is a public technical state that can be read again.

Second, they are repeatable. A daily check gives you a dated trail: what the record said yesterday, what it says today, and whether anything changed.

Third, they are data-minimizing. A public check does not need mailbox access, document access, device telemetry, identity-provider credentials, or employee activity data. The evidence stays scoped to what the internet already exposes.

What public signals cannot tell you

Public checks are deliberately limited. They cannot tell you:

• Who owns a vendor relationship.
• Whether a renewal was approved.
• Which employee should still have access to a SaaS tool.
• Which laptop is assigned to which person.
• Whether a contract has a cancellation notice window.
• Whether a company is compliant, certified, or audit-ready.

That is not a weakness of public-signal checks. It is the reason the second evidence source exists.

Internal Registers

Internal registers record facts that require organizational knowledge. They are entered, imported, reviewed, and maintained by the team responsible for them.

What only your team knows

Common governance registers are:

• Renewals & Vendor Register: vendors, SaaS tools, contracts, domains, certificates, owners, renewal dates, and review status.
• People & Accounts: people, roles, departments, account records, status, and CSV-friendly matrix views.
• Assets Register: hardware and software ownership records, assignment, status, license context, and maintenance notes.
• Access Reviews: systems catalog, access matrix, review entries, completion log, reviewer, next due date, and Access Review Register PDF evidence.

A scanner cannot know that "this SaaS tool renews on March 1, owner: Dana" unless your team records it. A register turns that human knowledge into evidence by adding structure, owners, dates, and review status.

Examples of register-only facts:

• Access review ownership: who reviewed a system, when the review was completed, and what needs follow-up.
• People and accounts: which person has an account on which system and whether the account is active, offboarding, or needs review.
• Assets: which laptop, software license, or device record belongs to which person or department.
• Renewals and vendors: who owns a renewal decision, when the renewal is due, and whether the record was recently reviewed.

Why manual-first is a feature

"Manual-first" can sound old-fashioned, but for small teams the issue is often not missing automation; it is missing ownership.

Manual-first registers help because:

• They force attribution. A record has an owner instead of being an inferred system guess.
• They avoid noisy discovery. Not every detected account or tool is meaningful without business context.
• They preserve privacy. The register contains what the team chooses to enter; it does not require directory sync, SaaS admin tokens, endpoint agents, or content access.
• They support CSV workflows. Existing spreadsheets can become structured records without pretending the spreadsheet was already evidence.

The tradeoff is upkeep. Registers must be reviewed on a cadence, but that review is exactly the governance work most teams need to prove anyway.

Why Governance Needs Both

Public checks and internal registers fill different evidence gaps. Combining them creates a more honest picture than either source alone.

| Question | Public-signal check | Internal register | |---|---|---| | Visibility | Public technical state visible from outside | Customer-maintained organizational knowledge | | Automation | Automated and repeatable | Manual-first, CSV-friendly, reviewed by people | | Owner | System timestamp and check result | Named record owner or reviewer | | Trust basis | Public record can be read again | Human accountability and review cadence | | Best at proving | SSL expiry, DNS state, RDAP/domain status, email-auth records | Vendor ownership, renewal dates, people, assets, access review completion | | Failure mode | Public change goes unnoticed | Register becomes stale or unowned | | Privacy profile | No internal access required | Contains only what the customer chooses to enter |

The practical rule is simple: do not maintain by hand what a machine can verify from a public signal, and do not pretend a machine can infer what only a responsible person knows.

Practical Examples

Example 1: an SSL expiry check reads the public TLS certificate and records whether it is valid and when it expires. That proves a public certificate state at a point in time; it does not prove the website is secure.

Example 2: a DNS check records current MX, TXT, NS, and CAA values. That proves public DNS state and drift; it does not prove the DNS provider account is well controlled.

Example 3: an RDAP/domain check records visible expiry and registrar context where available. That proves what the public registry data exposed; it does not prove billing is current inside the registrar account.

Example 4: a public DMARC check reads a DNS TXT record such as _dmarc.example.com and records whether a policy exists. That proves a public email-authentication record was present or missing; it does not read mailboxes or inspect messages.

Example 5: an access review completion log records that a reviewer completed the quarterly review, with a completion date, next due date, and snapshot counts. That is not public data. It is evidence because the team recorded the review event.

Example 6: a renewal register row says: "CRM subscription — renews 2027-03-01 — owner: Dana — last reviewed: 2026-06-12." No public check can discover that row. It is evidence because the team recorded ownership and review context.

The Privacy Consequence: Evidence Without Surveillance

Separating public checks from internal registers reduces the amount of sensitive data needed for governance evidence.

Public checks answer external technical questions without credentials. Registers answer internal ownership questions through customer-entered records. Neither requires reading email bodies, documents, chat messages, AI prompts, device activity, or employee behavior.

This matters because evidence collection should not create a larger governance problem than it solves. A COO or client may need proof that domains are monitored, renewals are owned, and access reviews happen. They do not need a tool that watches employees or scans content to get that proof.

What CertPilot Does — and Does Not Do — Here

CertPilot's checks read only public signals: DNS, RDAP, certificates, public email-authentication records, and selected HTTP response data documented in the methodology. External Footprint Monitoring covers the check layer, and the platform overview shows how checks combine with registers and reports.

CertPilot's registers contain only what your team chooses to enter or import by CSV: renewals, people and accounts, assets, and access reviews.

CertPilot does not log into your systems, does not connect to Google Workspace or Microsoft 365 today, does not discover SaaS tools automatically, and does not scan mailboxes, files, documents, chats, devices, or employee activity. It is not a vulnerability scanner, not an endpoint monitor, not certification, not legal advice, and not an audit substitute.

In Short

• Public-signal checks verify what is externally observable: SSL, DNS, RDAP/domain status, email-authentication records, and public response data.
• Internal registers record what only your team knows: renewals, owners, people, accounts, assets, systems, and access review events.
• Checks are automated; registers are customer-maintained. Both become more useful when rendered into dated evidence reports.
• The split supports data minimization: evidence without content scanning, internal system access, employee surveillance, or productivity scoring.
• Use checks for facts the internet can verify and registers for facts a named person must own.

Frequently Asked Questions

Can external checks see inside my network?

No. A public-signal check reads public records and public response data. It does not see private networks, internal applications, authenticated pages, mailboxes, documents, devices, or employee activity.

Is public-signal monitoring a security scan?

No. Public-signal monitoring reads visible technical records such as DNS, certificates, RDAP/domain data, and email-authentication records. It does not probe systems for vulnerabilities, run penetration tests, inspect application internals, or guarantee that an organization is secure.

Why not automate the registers?

Some register data may be automatable in the future, but ownership, review decisions, renewal context, and business meaning still need human confirmation. CertPilot's live registers are manual-first so teams can start with accurate customer-maintained records without granting private system access.

Is any employee data collected?

Only data your team chooses to enter in customer-maintained registers, such as a person's name, role, department, account records, or access review status. CertPilot does not monitor employees, score productivity, inspect messages, or read documents.

What public records do CertPilot checks read?

CertPilot checks public TLS certificate data, public DNS records, RDAP/domain registration data where available, public email-authentication records such as MX, SPF, DMARC, MTA-STS, TLS-RPT, and BIMI, plus selected public HTTP response data for trust-signal checks. The current product-level reference is the methodology page.