Read a control's version history and compare two dates, require independent testing and four-eyes sign-off, record segregation exceptions, delegate a control, change a definition and set what counts as passing.
Governance answers the questions an auditor asks before looking at any evidence: what the control looked like when it was tested, who was allowed to test it, who had to countersign the result and who was holding it at the time. ComplyTrain keeps that record for you as you work.
Task | Permission |
|---|---|
Read the history, compare dates, check integrity, read the segregation register | View controls |
Require independent testing or four-eyes sign-off; record or withdraw a segregation exception | Manage control governance |
Delegate a control, change its definition, set thresholds | Manage controls |
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
A control's configuration is versioned. A new version is recorded whenever one of these fields changes, whether on the control's tabs, through a bulk assignment or when a pack update refreshes the definition:
Area | Fields that create a version |
|---|---|
Definition | Name, objective, What it is, Guidance, When it acts, How it is carried out, What it reduces, key control, Category |
Scope and handling | Applicability, its reason, Your overall approach, the failure policy, the review interval, and the default cadence and method for new implementations |
Accountability | Owner, Whoever operates this control cannot test it, A second person must approve each test result |
Lifecycle | Status: activating, retiring and reinstating |
Other changes, such as delegating the control or changing its thresholds, do not create a version.
Each version is in force from the day of the change until the next version starts, so the periods follow one another without gaps. Every recorded test is tied to the version that was in force at the end of its tested period. Changing the control later never changes what an earlier result was about.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
Open the control and choose Governance. Under Configuration history, each version shows:
Item | Meaning |
|---|---|
Version 3 | The version number. The current one carries In force. |
Dates | When the version started and ended, or now for the current one. |
Reason | Why it changed, such as "Control created.", "Operational settings changed.", "Changed as part of a bulk update.", "Governance requirements changed.", "Retired:" with the reason given, "Reinstated from retirement." or the reason you gave for a definition change. |
Changed: | The fields that moved in this version. |
4 tests recorded against this version | How many test results describe this configuration. |
Check integrity | Recalculates the version's fingerprint. Intact means the stored record is exactly what was saved. Does not match its hash means it was altered outside ComplyTrain: treat that as a finding and tell your ComplyTrain administrator. |
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
Use Was this the same control? when an auditor asks whether the control tested in one period is the control you operate in another.
Enter On this date and And on this date.
Choose Compare.
Result | Meaning |
|---|---|
"The same control on both dates." | One version was in force on both dates. |
"Different: version 2 then, version 4 later." | The configuration changed between the dates. What moved: names the fields that differ. |
"Cannot say. At least one of those dates falls outside this control's recorded history." | One date is before the control's first version. |
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
Open the control and choose Ownership. Under Who may test it:
Setting | Effect |
|---|---|
Whoever operates this control cannot test it | The implementation owner, the control owner and anyone covering as delegate cannot record a test of it. Whether a delegate was covering is judged on the last day of the tested period, not today. A test from one of them is refused unless a segregation exception covers it. |
A second person must approve each test result | A recorded result counts towards effectiveness only after someone else with Approve control test results approves it. Until then, the control reads as though the test had not happened, and a failing result raises its deficiency only when approved. Approvers receive Control Test Awaiting Your Approval and find the result in Awaiting my approval. |
Each box saves as soon as you tick or clear it, and records a new version, "Governance requirements changed.". Turning either on does not affect results already recorded: each test keeps the rules that were in force when it ran, so you can tighten governance on a control that is already operating. A control pack can switch either on when the control is adopted.
A refused test explains what to do: have somebody else record the result, or record a segregation exception first. See test a control and get it signed off.
Product location: /qms/controls/governance. Choose Governance under Controls in the sidebar.
A small organisation cannot always separate operating a control from testing it. A segregation exception records, with a reason and an approver, that a named person or anyone may test a control they operate.
Choose Governance under Controls in the sidebar, or Where an exception to independence is recorded on the Ownership tab. The Segregation exceptions page opens.
Choose Record an exception.
Complete Record a segregation exception and choose Record it.
Field | What to enter | Rules |
|---|---|---|
Which controls | One control, or Every control in this organisation. | Naming one control is much easier to defend than a blanket exception. |
Which person | One person, or Anyone. | Name the person when you can. |
Why can duties not be separated here? | The real constraint, such as "We are four people and one of them runs the backups." | Required. |
Review it again on | The date the exception lapses. | Optional but strongly recommended. Cannot be in the past. Leave empty for No expiry. |
You are recorded as the approver, so you need Manage control governance. You cannot approve an exception that names you as the person who will test.
The register lists each exception with Applies to, Who, Why, Approved by, Until and Tests relying on it. A warning above the list counts the exceptions in force. Show withdrawn exceptions adds withdrawn ones.
The exception covers tests of periods that end on or before the review date. For a later period, a test by someone who operates the control is refused again. The approver receives Segregation Exception Expiring 30 days before the review date, in time to record a new exception or let this one lapse.
To end an exception early, choose Withdraw, enter Why is it being withdrawn? and choose Withdraw. The exception is kept, not deleted, because the tests recorded under it still point to it. From then on, a test by someone who operates the control is refused.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
Hand a control to someone for a fixed period, such as the owner's leave, so it does not fall due with nobody holding it.
Open the control and choose the action to delegate it.
Choose the person covering, the start and end dates, and the reason, such as "Parental leave".
Save.
Field | Rules |
|---|---|
Person | Required. |
Start and end dates | Both required. The end cannot be before the start. A delegation with no end date is an ownership change; change the owner instead. |
Reason | Optional. Explains why someone other than the owner holds the control. |
Within the period, the delegate receives the work the control's implementations generate, the Due board shows the delegate as the holder with "Covering while the owner is away", and overdue escalations go to the delegate's manager. The delegate counts as operating the control, so if independent testing is required they cannot test it for that period. The delegation ends by itself on the end date; to end it early, clear it. Delegating does not change the owner and does not create a version.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
The definition fields of a control from a pack are maintained by the catalogue: the Definition tab says "Maintained by the standard, not by you", and a pack update refreshes them. Change them only when your organisation genuinely operates the control differently from the catalogue wording.
Open the control, choose Definition and choose the action to change it.
Change any of the name, objective, What it is, Guidance, When it acts, How it is carried out, What it reduces, key control and Category.
Enter why you are changing it. The reason is required.
Save.
The reason becomes the change reason of a new version. For a pack control, the library shows an edited badge and the Definition tab states "You have overridden a catalog field, so this control no longer receives catalog updates." with your reason. From then on, pack updates leave the control alone; see adopt control packs and import controls.
For a control you authored, the same action changes the definition and records your reason.
You never need this for the owner, applicability, approach or failure policy: those belong to your organisation and survive every pack update.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
When an external system reports on a control, it sends how many things it examined and how many were satisfactory. The thresholds decide what that means.
Threshold | Meaning | Default |
|---|---|---|
Passing percentage | At or above this share, a result reads as effective. | 100% |
Partially effective from | At or above this share, but below the passing percentage, a result reads as partially effective. Below it, ineffective. | 1% |
Both accept 1 to 100, or empty to inherit. The partial threshold cannot be above the passing percentage and, after inheritance, must leave a band between them.
Set them for the whole control with the action on the control, or for one implementation in Review design under What counts as passing, using Passing percentage, Partially effective from and Save thresholds. An implementation's thresholds override the control's, so production can be held to a stricter standard than a test environment. Currently inherited: 100%. shows the value in use.
Saving re-works the results already reported under the new thresholds. Each result whose verdict changes is replaced by a corrected result that records why, and nothing is rewritten. The message reads, for example, "3 already-recorded result(s) changed verdict under the new threshold." See external reporting.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Governance or Ownership.
Your ISO/IEC 27001 access review, Access rights, is owned by the IT manager, Sam Patel. Internal audit tests it each quarter.
In May, the quality manager opens Ownership and ticks both Whoever operates this control cannot test it and A second person must approve each test result. Each box saves separately, so versions 3 and 4 appear on Governance, each with "Governance requirements changed.".
Sam goes on parental leave from 1 July to 30 September. The quality manager delegates Access rights to Alex Kim for those dates with the reason "Parental leave". The third-quarter review task goes to Alex, and the Due board shows Alex "Covering while the owner is away".
In October, Maria from internal audit records the third-quarter test. Alex could not have recorded it, because Alex was covering on the last day of the period. The quality lead approves the result in Awaiting my approval, and it starts counting.
The backup control also requires independent testing, but the organisation has four people and Alex both runs and checks the backups. The quality manager records a segregation exception for that control, for Alex, with the reason "We are four people and one of them runs the backups." and a review date next March.
In January the certification auditor asks whether the access review was the same control in the first and third quarters. Compare 31 March and 30 September: "Different: version 2 then, version 4 later.", and What moved: names the two governance settings.
