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.
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 catalogues | The public catalogue of known data breaches: which organizations were breached, when, how many accounts, and what was exposed. | No — a published catalogue. |
| 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. |
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.
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.
Three words do a lot of work in our reports, and mixing them up is how security reporting quietly misleads people.
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.
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.
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.
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.