Ansvar AI docs
    ansvar.eu →

    Your control scope repository

    The Control Library gives your agent one NIST 800-53 control spine with framework catalogs — ISO 27001, NIS2, DORA, CRA, BSI C5 and more — and reviewed mapping links growing from that spine (ISO 27001 and other editions returned by coverage), served through the gateway at Team tier and above. The control scope repository is the other half: a private GitHub repository, provisioned by Ansvar for your organization, that records which controls apply to you, the decision context behind each choice, and every approval — as reviewable git history your auditor can read end to end.

    The split is deliberate. Ansvar's library holds the control corpus and the reviewed mapping graph; your repository holds only your decisions about them. Your agent reads one and proposes to the other — and people, never agents, approve.

    The operating model

    • Reads go through the gateway. Your agent asks the Control Library tools — crosswalk, get_control, coverage and the rest — over the same OAuth connection it already uses for legislation. Every answer names the exact library commit that produced it, so work against a locked scope is verifiable.
    • Writes are pull requests, never gateway calls. There is no gateway write tool, by design: an unreviewed agent write can never become ground truth. The agent drafts profile changes, mapping requests, and review verdicts as files in your repository and opens a pull request with your own GitHub access.
    • Two approvals merge. A repository ruleset requires one approval from your scope-owner team and one from Ansvar's mapping owners, plus a green validation check. The validator is what proves the detail: the two declared reviewers approved the exact commit, and identifiers and locks match the exact library release your scope is pinned to. Merged main is your approved scope history.

    How it fills

    You export your ISO 27001 Statement of Applicability from your ISMS tool (CSV or XLSX). Ansvar imports it against a released library version, and a pull request comes back with your scope as data: one profile per certification scope with your applicability decisions and implementation statements, a lock file pinning the exact library release, and generated reports. Nothing becomes your approved scope until your people have reviewed and approved it.

    From a scope to an implementation assessment

    Start with START-HERE.md in the repository Ansvar provisions for you. Confirm your locked library release and named reviewers, then open the scope portal with python .github/scripts/scope_portal.py. Visit http://127.0.0.1:8790 on the same machine. The portal is a read-only workbench; changes still go through files and pull requests. Each pull request also includes a generated HTML portal artifact for reviewers.

    1. Register your organisational scopes and the frameworks that apply to each. Record requirement-level exceptions with their basis and decision owner; a parent scope does not imply inheritance.
    2. Record implementation activities, their planned or implemented status, and the canonical controls they address. Reference evidence and internal policy catalogues by pointer.
    3. Assess implementation per control, keeping design evidence and operating evidence separate. Record gaps with an owner, target date and treatment. The portal joins these records so reviewers can see what work remains.
    4. Ask your agent to draft the next change using the portal's task prompts. Run the repository's preflight, inspect the pull request and obtain the required approvals on the exact commit.

    The pinned reference index lets the preflight check control, framework, requirement and policy identifiers without a library credential. When neither the index nor its lock pin is present, the preflight reports that it checked structure only. A missing or mismatched pinned index fails the preflight. A structural pass is not approval of the scope or proof of implementation. The repository's docs/portal-guide.md and docs/activity-guide.md describe the file contracts.

    Reviewing the mappings with your own agent

    Once the lane opens, your agent will walk the ISO → NIST candidate mappings requirement by requirement, and your team will record one verdict per requirement:

    • accept — the candidate set fits your scope, recorded as a fingerprint of the exact set at your locked release;
    • accept-gap — no candidates exist and you accept that, on the record;
    • change — you propose a correction, which Ansvar triages: accepted corrections land through a reviewed library release and you re-accept the refreshed set; declined ones can close as an accepted gap;
    • defer — parked with a reason, visibly blocking completion until you decide.

    The queue drains to zero: every applicable requirement decided, at a pinned release, with the approval trail attached. A verdict is your scope decision — it never edits the shared mapping graph and never becomes a coverage claim; those change only through Ansvar's reviewed releases.

    Your repository ships with its own guides, including the paste-ready batch prompt and the full verdict rules — they are the contract; this page is the overview.

    What stays out of your repository

    Licensed standard text (identifiers and references only), Ansvar's mapping graph, evidence files and raw SoA exports, credentials, secrets, and personal data beyond GitHub handles — implementation statements record decision context, not attached evidence. The repository's checks validate file shapes and identifiers; they do not scan free text, so this rule is yours to keep in statements, reasons, and notes.

    Getting one

    Scope repositories are provisioned per customer as part of a Team or Company engagement — Ansvar sets up the repository from the library's template, imports your SoA, and configures the approval gate with your named scope owners. Talk to us to start, or see the ISO standards add-on if you also want licensed clause text cited alongside your scope.