Small companies rarely run a network in the old sense. They run edge settings, DNS records and access rules spread across a few accounts, each easy to change and easy to leave behind. The rule that is wrong is usually wrong because it was written for a service that no longer exists.
Small companies rarely run a network in the old sense, so the exposure is usually something nobody meant to publish. We find services answering publicly that were meant to stay internal, and DNS records still pointing at things that no longer exist, including subdomains somebody else could now claim.
A rule that exists and a rule that acts are different things, and the difference is invisible from the console list. We read firewall and web application firewall rules for the ones set to log rather than block, the endpoints that need rate limiting and the ones with none, and the outdated protocol versions your TLS configuration still accepts.
Access paths outlive the projects they were built for. We read the zero-trust policies in front of each application and tell you who can get through them, which is rarely the list anybody expects.
Those questions are the shape of it, not the inventory. Underneath them is a larger set of individual settings we read on each platform, and it moves every time a platform ships something new.
Where a CIS safeguard fits the evidence, the finding carries it, so the answer you give an auditor is the answer we already gave you. Where none fits, we leave it unmapped rather than claim a control we cannot stand behind.
A finding names the rule, the record or the hostname, not just the category it sits under.
Every change is prepared for you, made only once you approve it, logged, and reversible where the platform allows. How that works
Today we read edge and network settings from Cloudflare, AWS and Vercel. More platforms are in development.