How our checks stay safe —
and what that rules out.
Letting anyone run security checks against your organization is an act of trust, and most vendors ask for it without explaining what actually happens. This page explains the method: what we read, what we never touch, and how we tell you when a finding is a strong lead rather than a proven fact. It is deliberately specific, because a promise you cannot check is just a nice sentence.
Reviewed by the founder · last updated 23 August 2026. If anything on this page is ever untrue of what we actually do, that's a bug: security@familysentinel.org reaches a person.
Where every finding actually comes from.
Six sources. All of them are either public record, or something you explicitly granted us read-only sight of.
| Source | What it is | Does it touch you? |
|---|---|---|
| Public DNS | The records your domain publishes to the world so mail can be delivered — SPF, DKIM, DMARC. Anyone can read them; that is their purpose. | No — we query the public directory, not your server. |
| Certificate transparency logs | A public, permanent ledger of every TLS certificate ever issued for your domain. It is the list an attacker starts from, so it is worth you knowing what is on it. | No — a public ledger. |
| Domain registration records | Which lookalike variations of your name someone has registered, and whether they are configured to send mail. | No — registry and DNS records. |
| Published breach catalogs | The public catalog of known data breaches: which organizations were breached, when, how many accounts, and what was exposed. | No — a published catalog. |
| Cached third-party scan data | Internet-wide scanning that other organizations already perform and publish. We read their cached results; we never run the scan ourselves. | No — we read someone else's already-published observation. |
| Your Workspace / M365 audit log | The security record your platform already keeps — sign-ins, admin changes, forwarding rules, app grants — visible to us only because you granted read-only access, revocable by you in one click. | Read-only, with your explicit grant. |
What our AI does, and does not, decide.
Our AI accelerates analysis; it does not replace human judgment. It reasons only over a case file we assembled from the sources above — it cannot invent a fact, look anything up on its own, or take an action. Every finding it touches still reaches a person before it reaches you, and nothing is ever auto-closed on the model's say-so.
The inference constraint, stated plainly: facts come only from our own data and the checks above; the model's only job is to reason over the case file it is handed. If a fact is not in that file, the model does not get to supply it — and if a verdict cannot be traced back to a source on this page, it does not ship.
The capabilities we chose not to have.
These are real techniques used by serious security products. We do not do them, and the reason is the same in each case: doing them responsibly requires controls that a service at our size and price cannot honestly provide, and doing them irresponsibly is how a security vendor becomes the incident.
- We do not attack your systems to prove a weakness is real. Autonomous exploitation needs signed authorization for every system in scope, and an agreed plan for the day a test causes an outage.
- We do not capture or reuse your staff's credentials. Some products phish your people and then log in with what they catch to demonstrate the blast radius. We never hold your credentials at all — that is the promise the whole company rests on.
- We do not move laterally through your network. There is no agent, no implant, and nothing of ours running inside your environment.
- We do not plant anything in your systems. If a decoy or tripwire is ever useful, we give you the recipe and you place it — our access stays read-only.
- We do not submit your files to public sandboxes. Most free malware-analysis services make submissions publicly searchable, and an elderly customer's attachment is not ours to publish.
If your organization genuinely needs a full penetration test, that is a good thing to want, and we will tell you so. It is a separate engagement with a signed scope and rules of engagement — never something that happens quietly inside a monitoring subscription.
Observed, inferred, or unchecked — we always say which.
Three words do a lot of work in our reports, and mixing them up is how security reporting quietly misleads people.
Observed
We read it directly and can quote it. "Your DMARC record says p=none" is observed — the record is right there, and you can look it up yourself in a minute.
Inferred
A strong lead we did not prove. A public server advertising an old version number is associated with a known-exploited vulnerability — but banners are frequently stale or back-ported, so we say inferred and ask you to check the real patch level.
Unchecked
The check did not run — a source was down or a lookup timed out. This is reported as a gap on the front page, never as a pass. An unchecked thing is unknown, not clean, and a report that blurs those two is worse than no report at all.
The failure we designed against.
A broken security check almost never announces itself. It returns nothing, and nothing looks exactly like good news — an empty result reads as "no problems found", a missing finding reads as "you fixed it". Every serious monitoring failure we have investigated, in our own systems and in others', has that shape: something reported healthy while doing nothing at all.
So the reporting is built so the comfortable conclusion is unreachable without evidence. A finding is only marked fixed if the check that would have re-found it actually ran and came back empty. A source that could not be reached is counted as unknown and named on the front page. And the report will not say "all clear" while any check is missing — even when there is nothing else to report.
Common questions
Do your security checks touch our systems?
No. Every external check reads public records — DNS, certificate transparency logs, published breach catalogs, and cached third-party scan data collected by others. We do not send traffic at your servers, we do not scan your network, and we do not test whether a weakness can be exploited.
Could one of your checks break something?
There is nothing for it to break. A check that only reads a public DNS record or a published catalog cannot take a server down, lock an account, or corrupt data — which is precisely why we chose this method for organizations with no IT staff standing by.
Why don't you run a real penetration test?
Because a genuine penetration test needs signed authorization scoping every system, specialist insurance, and an agreed plan for when a test causes an outage. Those are the right controls, and a service at our price point cannot honestly provide them. If your organization needs a true pentest we will say so and help you scope one properly — it is a separate, authorization-gated engagement, never something that happens quietly as part of monitoring.
What does it mean when a finding says 'inferred'?
It means we read it rather than proved it. For example, a public server may advertise the software version it is running, and that version may be associated with a vulnerability attackers are exploiting. That is a strong lead, but version banners are often stale or back-ported, so we label the finding as inferred and ask you to confirm against your actual patch level. We will not use the word 'proven' for something we did not test.