Controls

What the screen is for#

The screen is used to find a control and see what covers it, what it lacks and what rests on it. You do not edit a control here: implementation comes from the assessment, verified tasks, evidence and tests; Annex A applicability is set in the statement of applicability.

Who can do what#

Anyone who can open the page reads this screen. There is no write action.

A control's state#

The state is worked out, never typed:

• "Excluded": the control is left out of the statement;
• "Not implemented";
• "Test failing": a measured test fails (it outranks missing evidence);
• "Evidence to provide": an expected piece of evidence is missing or older than its frequency;
• "In place": implemented, evidence current, no failing test.

Stale evidence counts for neither the state, the score, nor the rule "no closing without evidence": it is the same rule everywhere.

Step by step#

1. Read the cards: "Implementation" (share of applicable controls implemented), "Evidence" (share with current evidence) and "Controls by domain". Clicking a domain filters the list.
2. Search by code, title or keyword, or filter by "Domain" and "State". A filter can come from the dashboard: a line says so, and describes only what is applied.
3. The table shows, per control: state, owner, current evidence out of expected, tests ("No test" or "1 failing out of 3"), open risks, and the requirements covered per framework.
4. "Details" opens the drawer: domain, sub-domain, function (Govern, Identify, Protect, Detect, Respond, Recover), owner, evidence, open risks that rely on this control, assets concerned and linked incidents.
5. "Refresh" rereads the data.

Write how the control is implemented, review a piece of evidence#

In a control's drawer, the "How we implement it" field describes what you actually do: the tool, the frequency, who answers for it (by role). It is edited with "Save", in both editions, by whoever edits the statement of applicability or by the person the control is assigned to. The auditor reads it in the controls file of the audit pack.

Edition: Advanced "Propose a draft" asks the assistant for a text based on the control, its tasks, the answers to the assessment and the name of the attached evidence. The text you take is in the field, and is saved only with "Save". In a control's list of evidence, "Review with the assistant" gives an opinion ("Covers what is expected", "Partly covers it", "Does not cover it"), what is missing and notes, from the piece's name, type and date: it does not read the content of a file. What goes to the model: AI assistant.

Import the state of controls#

"Import" and "Download the template" (for whoever edits controls) fill in the implementation state, the owner, the due date and the justification of controls that exist, from an Excel workbook. See Import and export with Excel templates.

What the auditor will take from it#

The trail from requirement to control, from control to its dated evidence and its test, and from control to the risks and incidents attached to it.

Common controls and the rest of the app#

• Evidence (file, reference, frozen Jira query) is filed on a control and, where it answers one, under one of its expected pieces. Older evidence the app could not attach to a single control stays "to attach".
• Tests are the monitors of monitoring: the latest result of a monitor a control names turns an implemented control to "Test failing" if it fails.
• Risks cite controls; the ticket panel shows the task's controls, their state and the requirements covered.
• The rule "no closing without evidence" refuses a closing if neither the task nor its controls have current evidence.

Known limits#

• Control titles and explanations come from the content catalogue.
• Attaching evidence or a monitor to a control is not yet done from this screen.
• Tests are not yet objects (owner, deadline, history): they are monitor results.