Banks and healthcare organizations ask specific questions before they'll hand over infrastructure configuration. Here are direct answers — how data is handled, how findings are generated, how AI is used, and how evidence is stored.
We analyze declared infrastructure configuration — a Terraform, CloudFormation, ARM/Bicep, or GCP Deployment Manager file, or a landing-zone posture document you provide. We do not connect to your live environment, request cloud credentials, or run anything against production systems.
This is static analysis: we read what your configuration says should exist, not what's actually running. That boundary is stated in every report we deliver, not just here.
Configuration files are transferred using your preferred secure method — encrypted email, secure file transfer, or your own portal. We don't require a specific channel; we work within your existing data-handling policy, not around it.
No. Every finding is produced by deterministic rule evaluation against your declared configuration — a fixed set of checks looking for specific conditions (MFA not enforced, encryption not configured, logging disabled, and similar), each one mapped to a specific regulatory citation before any report is written.
Nothing about whether a finding exists, what severity it carries, or what citation it maps to is decided by a language model. Two runs against the identical configuration will always produce the identical findings.
In exactly one place: drafting the plain-language Executive Briefing and Board Reporting Narrative sections that summarize findings which were already fixed by the deterministic engine before the model ever runs. The model writes prose around numbers it cannot change.
It runs on a local model, on-premises — never a cloud API. Your configuration data and findings never leave the assessment environment for this step. If the narrative generation fails, times out, or the local model isn't available, the report is delivered without it — the deterministic findings, evidence, and corrective action plan are never affected.
Output is also automatically screened: if narrative text ever contained defense-sector-specific terminology inappropriate to a commercial engagement, it's discarded and the deterministic sections are used alone.
Locally, within the assessment environment. Each engagement's findings, reports, and re-assessment history are stored as files on the system running the assessment — not uploaded to a shared cloud service or a multi-tenant database.
Re-assessments are compared against your organization's own prior runs to build an evidence-trend record over time — new findings, resolved findings, and how long open items have remained outstanding against their target remediation window.
We say this plainly in every report, not just here. Technical-safeguard assessment does not cover organizational and administrative safeguards — a written risk assessment narrative, workforce training records, sanction policy documentation, service-provider oversight contracts, incident response plan testing, or a Qualified Individual's sign-off. Those require evidence beyond infrastructure configuration, and remain your organization's responsibility, supported by your counsel or compliance officer.
Ask before you engage — we'd rather answer now than after.