CONTROLSPEC · RELEASE 0.17.1 · NO CLOUD CREDENTIALS COLLECTED · VALIDATE DATA-SOURCE NAMES BEFORE USE

Evidence-driven cybersecurity assurance

Start with your environment. End with a reviewed control result.

Choose the role and technologies you actually operate. Then select a control pack to see what evidence to provide, which platform-specific query applies, how it is monitored, and what the result means.

10control objectives
3platform paths
30reference queries
5evidence input contracts

Queries run in your own authorized environment. This project has no ingestion endpoint and never receives credentials, tenant data, or production evidence. Every generated query still requires validation in your own tenant before operational use.

Environment profile

Tell us what you operate before choosing a pack.

Your cloud and monitoring choices control which working-platform buttons appear below. The profile also changes recommendations and flags technology mismatches.

How do you work?Choose the closest operating model.

What technologies are in scope?Select every relevant source, including more than one cloud.
What do the badges mean?Every technology below states how it reaches a published query

These packs only ever run a query in Microsoft Sentinel, AWS, or Splunk. Everything else you select is either a source those queries read, or a system you export evidence from. The badge tells you which, so you can see whether your stack is covered before choosing a pack.

Direct query
A published query names this technology's own tables or API. Nothing to export or forward. Microsoft Entra ID and AWS IAM work this way.
Via Splunk
No query reads this product's own API, but the published Splunk searches read vendor-neutral sourcetypes — directory:users, privileged:assignments, backup:jobs, config:snapshot, network:rules — rather than any vendor's tables. Forward the product into Splunk with that sourcetype and the documented fields, and the existing query covers it with no new query written. This is how Okta, Veeam, Rubrik, Commvault, VMware, and Google Cloud are covered.
Via CSV export
Export into one of the five open CSV contracts that the published queries join to. For a CMDB or a ticketing system this is not a workaround — supplying evidence the cloud cannot produce is exactly what those systems are for here.
Roadmap
Named and scoped, but nothing in this release reads it. Listed so the gap is stated rather than left for you to discover.

Open How this connects under any option for the exact index, sourcetype, fields, or contract file involved.

Implementation pack library

Choose a category, then a control.

Start with the area you are reviewing. Packs are filtered to your selected operating profile unless you choose to view the full library.

Implementation guide

Follow the selected pack from requirement to review.

Five steps, from the control objective to a reviewed result. The objective stays fixed — the platform can change at any point without it changing.

Selected pack
1

Step 1 · The requirement

Source requirement vs. local implementation choice

Organization-defined parameters

2

Step 2 · What you must supply

Evidence inputs

Instructions shown for Microsoft Sentinel.

3

Step 3 · How it is monitored

Platform-native detection query

The query below follows the working platform selected above and updates automatically.

Customise this query

Adjust the available settings. The query updates automatically as you type or change platforms.

Your input stays in this browser
Values supplied or changed Source read by this query
4

Step 4 · How it runs continuously

Show continuous monitoring configuration
Continuous monitoring configuration
5

Step 5 · What the analyst sees

Console preview and human review

Open this workspace when you are ready to generate a synthetic console preview and review the possible implications.

Open analyst review workspaceGenerate the preview only when needed

As it would appear in the console

All simulated alerts for this control

What a reviewer still has to decide

    Implementation snapshot

    Know what the query needs before you run it.

    A compact view of platform data, supplied evidence, permissions, and the monitoring destination for the selected control.

    The JSON profile carries the objective, organization-defined parameters, evidence contract, platform implementation, monitoring configuration, outcome vocabulary, human-review boundary, and validation status as one structured artifact. It is OSCAL-informed and is not an OSCAL document. It contains no credentials, tenant data, query results, or evidence values.

    Evidence record inspector