See how a standard's clauses, your organisation's controls and the mappings between them fit together, what a mapping claims and what proves it, and what feeds the Statement of Applicability.
A standard describes what is expected of you. A requirement gives one of those expectations an identity you can track. A control describes what your organisation actually does about it, and how you run and test it. ComplyTrain connects them with mappings, so one control can answer several requirements across several standards, and each standard can show which of its clauses have something working behind them.
Product location: /qms/controls. Open the Library in Controls.
Standards use the word control for their own items: ISO/IEC 27001 Annex A lists "controls" such as 5.18 Access rights. In ComplyTrain those items are the standard's requirements. You scope them, map to them and review them on the standard side.
The Controls library holds your organisation's controls: what each is for, who owns it, whether it applies to you, where it runs and how well it works. A control that came with a standard starts from the catalogue's wording and is then yours to operate.
The two answer different questions. The requirement says what is expected. The control says what you do. Similar wording or a matching number does not connect them; a saved mapping does.
Product location: /qms/controls. Open the Library in Controls.
Record | What it contributes |
|---|---|
Standard | The standard you adopted, its edition and its source documents. |
Requirement | One identifiable item of the standard, with its code, text and scope. Your own requirements can represent other sources, such as a customer contract. |
Control pack | The controls ComplyTrain maintains for a standard, added to your library when you adopt it. |
Control | Your measure: its definition, applicability and reason, owner and approach. |
Mapping | The link between one control and one requirement, with its coverage, whether a person has confirmed it, and the rationale. |
Implementation | Where, how, how often and by whom the control is carried out. |
Test and evidence | What was examined, the verdict and the evidence behind it. Tests decide the control's effectiveness. |
Statement of Applicability | A versioned, approved record for one standard of which controls apply, why, and whether they are in place. |
Each record answers its own question. A copied paragraph, an adopted definition, a mapping and a passed test are four different things.
Product location: /qms/controls. Open the Library in Controls.
Control packs arrive when you adopt a standard. See adopt control packs and import controls.
Your own controls are created with New control, for measures no pack provides. See build and maintain your control library.
Imports bring in a spreadsheet, or controls suggested from your risk register's existing-control notes.
Drafts are prepared by the Controls Assistant and activated after review. See define and review controls with AI.
All four end up as the same kind of record, with the same rules, versioning and plan limits.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Scope and handling.
Two decisions sound alike and are made in different places:
Decision | Where | What it says |
|---|---|---|
Is this clause in scope? | On the standard: In Scope, Out of Scope or Partial, set during the standard's setup and in its scope view. | Whether the standard's expectation applies to your organisation. |
Does this control apply to you? | On the control's Scope and handling tab: In scope, Not in scope or Partly applicable. | Whether your organisation operates this control. |
Framework coverage shows the clause's scope in its Scope column and reports an excluded clause as Excluded. The Statement of Applicability reports each control's applicability and reason. Keep the two consistent: an organisation with no offices that excludes ISO/IEC 27001 7.4 Physical security monitoring should also mark its control Not in scope with the same reason.
Product location: /qms/controls. Open the Library in Controls.
Suppose the IT manager runs a quarterly access review: each system owner confirms or revokes every account on the finance system, the CRM and Microsoft 365. That is one control, Access rights, from the ISO/IEC 27001 pack.
The same review also satisfies a customer's security schedule, which you hold as your own requirement: "The supplier reviews user access at least quarterly." Map the one control to both requirements rather than creating a second control. Each mapping has its own coverage and rationale, and the review's tests count for both.
A requirement can also need several controls. Access rights under ISO/IEC 27001 might be met by the access review (Primary), the joiner-mover-leaver process (Supporting) and the privileged access review, which covers administrator accounts only (Partial).
Create separate controls only when the objectives or procedures genuinely differ. When one control runs in several places, give it several implementations; see define where and how a control operates.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Requirements.
How | State it arrives in |
|---|---|
Adopting a standard adds the catalogue's mappings for its pack controls. | Suggested, not yet confirmed. |
Suggest mappings from the catalogue on a standard's Framework coverage page. | Suggested, not yet confirmed. |
Accepting ComplyTrain's proposals on a control's Requirements tab, or all at once from the library's banner, such as Accept all 12. | Confirmed. |
Mapping a control to a requirement yourself on its Requirements tab, with a rationale. | Confirmed. |
The Controls Assistant proposing a mapping. | Suggested, not yet confirmed. |
Creating, confirming or removing a mapping needs Manage Requirements, including accepting ComplyTrain's proposals or the assistant's suggestions. See map controls to requirements for the steps.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control and choose Requirements.
Coverage | What the mapping claims |
|---|---|
Primary | This control is a main way your organisation meets the requirement. |
Supporting | It contributes alongside the main measures. |
Partial | It meets part of the requirement; the rest needs other controls. |
Coverage is reported word for word in the Statement of Applicability, so claim Primary only where the control genuinely is the main way the clause is met.
A suggested mapping is marked "not yet confirmed by anyone here" in the library and has a Confirm button on the control's Requirements tab. Until someone confirms it, Framework coverage counts its clause as Awaiting review: "Not a gap, but not yet evidence either." Mappings the assistant suggests stay out of the Statement of Applicability until confirmed.
Product location: /qms/controls/standards/{standardId}/coverage (fallback: /qms/controls). Choose the standard in the Library's Standard filter, then Framework coverage.
A mapping says a control addresses a clause. It does not say the control works. Effectiveness comes only from tests.
View | What it counts |
|---|---|
Framework coverage | Each clause as No control, Awaiting review, No primary control, Covered or Excluded, with Working showing how many of its controls are effective and how many are not yet tested. |
The standard's evidence matrix | A clause's controls as sufficient only when they are rated effective. An untested control is not counted as working. |
Both | Retired controls are left out. |
So a clause can be Covered by a confirmed primary mapping and still have nothing proven. Test the control to close that gap; see test a control and get it signed off.
Product location: /qms/controls. Open the Library in Controls.
A document name and page number identify the passage in the standard. They help a person or the assistant read the original wording in context. The requirement record is the stable identity that scope decisions, mappings and coverage use.
Finding a passage in the knowledge base does not show that its requirement record exists. Describing a control in a conversation does not save a control or a mapping.
When you discuss an Annex A item, be clear which you want: "Read this item on its page", "Show its requirement record", or "Show the controls mapped to that record". Use the standard's knowledge sources for the passage and the requirement catalogue for the record.
Product location: /qms/controls. Open the Library in Controls.
Check the standard, its edition and any scope or search filters, then search by the item's code.
If the passage exists but its requirement record does not, give whoever maintains your standards the standard, edition, item code and page. Creating another control does not create a missing requirement.
For an obligation that belongs only to your organisation, such as a clause in a customer contract, create your own requirement and keep its source. Then map your existing control to it.
Product location: /qms/controls. Open the Library in Controls.
Give the Controls Assistant both the source and your operational context. For example: "Read ISO/IEC 27001 Annex A 5.18 and find its requirement record. Compare it with our Access rights control. Propose a mapping with a coverage and a rationale, and say what still needs evidence."
The assistant proposes; a person decides. Its mappings arrive as suggestions for someone with Manage Requirements to confirm or remove. Afterwards, ask "Which mappings did you save, and which still need confirming?", then check the control's Requirements tab. See define and review controls with AI.
Product location: /qms/controls/standards/{standardId}/soa (fallback: /qms/controls). Choose the standard in the Library's Standard filter, then Statement of Applicability.
Each standard has its own Statement of Applicability. Open it from the standard, or from the library once you choose the standard in the Standard filter.
A new version lists the standard's applicable, non-retired controls against their clauses. Each row shows whether the control applies, the reason, whether it is in place and its evidence. The reason comes from the control, for controls that apply as well as those that do not, and carries into each new version. Rebuild from current controls keeps the reasons already written and asks before discarding anything.
When the version is complete, submit it. An approver with Approve Statement of Applicability approves and signs it, and the signed version is filed in the document vault as a read-only record. Later changes to your controls go into a new version. One control can appear in several standards' statements, each with its own mappings and scope. See prepare, approve and sign a Statement of Applicability.
