Cardinal Ruler / Compliance

How Cardinal Ruler supports your compliance posture

Your auditors ask four questions. Answer with a folder.

Every framework they work from asks the same things about a configuration change. This page maps each answer to the framework that asks for it, with a citation to the framework itself rather than to a blog about it.

  1. Q1

    Was the change authorised?

  2. Q2

    Was it tested before it went live?

  3. Q3

    Could the requester approve their own work?

  4. Q4

    Where is the record, and who owns it?

The frameworks that ask for controlled change

Three frameworks put change control at the centre of what they test. In each case the evidence they ask for is what a deployed change request already contains: who asked, who approved, what was checked, and what happened.

  • 01

    ISO/IEC 27001:2022

    any certified organisation

    The standard asks

    Annex A control 8.32 (change management) requires changes to information systems to be planned, authorised, tested and documented. Control 8.9 (configuration management) requires configurations to be recorded with a history of changes. Control 5.3 requires conflicting duties to be segregated - and change management is a textbook conflict area.

    Cardinal Ruler gives you

    A formal change package per configuration change, an approval covering the whole plan as frozen at submission, and pre-flight and post-deploy checks on the record. Where a target site requires approval before anything is deployed to it - a gated target - the requester cannot approve their own change.

    Source: ISO/IEC 27001:2022 (opens in a new tab), Annex A 8.32, 8.9, 5.3

  • 02

    SOC 2

    service organisations

    The criteria ask

    “The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.”

    Cardinal Ruler gives you

    Where Jira is in scope for a SOC 2 report, every one of those verbs lands as an artefact - the package is the authorisation, the pre-flight report is the test evidence, the approval commit is the approval, and the validation report closes the loop. The 2022 revision added points of focus on testing and implementing changes, which is the part hand-typed configuration can never evidence.

    Source: AICPA Trust Services Criteria (opens in a new tab), CC8.1

  • 03

    DORA

    EU financial entities

    The regulation asks

    Article 9(4)(e) of Regulation (EU) 2022/2554 requires documented policies, procedures and controls for ICT change management. Article 17 of the supporting technical standard spells them out: independence between the functions approving changes and the functions requesting or implementing them, clear roles, documented purpose and outcome, and fallback procedures.

    Cardinal Ruler gives you

    Exactly that separation for the Jira estate - the approver on a gated target is never the requester, every state change is a signed timeline entry, and a change that fails verification ends in an explicit rolled-back or superseded outcome, on the record.

    Sources: Regulation (EU) 2022/2554 (opens in a new tab), Art. 9(4)(e); CDR (EU) 2024/1774 (opens in a new tab), Art. 17

Two more your auditors may bring

  • 04

    SOX · IT general controls

    listed companies

    The audit asks

    Where Jira workflows sit in financially relevant processes, auditors testing internal control over financial reporting under Section 404 examine IT general controls over change: authorisation, testing evidence, and segregation between who builds and who deploys. There is no numbered control to quote - the test is the auditor's, performed under PCAOB Auditing Standard 2201.

    Cardinal Ruler gives you

    Ready-made ITGC evidence - a documented request, a risk-visible plan, an approval distinct from the requester, and a deployment record an auditor can read without Jira and without Cardinal Ruler.

    Source: PCAOB AS 2201 (opens in a new tab), An Audit of Internal Control Over Financial Reporting

  • 05

    ISO/IEC 20000-1:2018

    IT service management

    The standard asks

    Clause 8.5.1 requires a change management policy and process - from the request for change, through assessment and approval, to deployment. It is the certification form of the ITIL change enablement practice your team already speaks.

    Cardinal Ruler gives you

    That process as the pipeline itself: request, pre-flight assessment, approval, scheduled deployment and verification are states every change passes through - the process documentation and the process execution are the same artefact.

    Source: ISO/IEC 20000-1:2018 (opens in a new tab), clause 8.5.1

One mechanism, many names

Auditors name the same four controls differently across frameworks. Cardinal Ruler implements each one once, and the record serves them all.

  • Requester ≠ approver segregation of duties

    On a gated target the person who raised the change cannot approve it. ISO 27001 calls this control 5.3; DORA calls it independence of functions; SOX auditors call it SoD.

  • Approval covers a frozen plan authorised change

    What was approved is what deploys - nothing more. The authorisation evidence every framework asks for is the approval commit itself.

  • Pre-flight and validation reports tested change

    A read-only check against the target before approval, and a post-deploy check against the approved specification after. Both committed to the record.

  • A record your organisation owns audit evidence

    One folder per change in a Git repository under your retention and your jurisdiction - readable by an auditor without Jira and without Cardinal Ruler.

What this page does not claim

A compliance page earns trust the same way the product does: by saying exactly where the claim ends.

  • Not a certificate

    No tool makes an organisation compliant. Cardinal Ruler supports your compliance posture with evidence; your policies, your controls and your auditors do the rest.

  • A scoped claim

    The DORA claim covers what the product covers. Cardinal Ruler handles ICT change management for your Jira estate - it is one control in your DORA programme, not the programme.

  • Not claimed

    PCI DSS, HIPAA and NIS2 make no appearance above. Where Jira genuinely falls in scope for those, the same record helps - but that is your assessor's call, not a promise made here.

  • Two different claims

    Product support and company certification are different things. This page describes what Cardinal Ruler helps your organisation evidence. Separately, VMotion IT Solutions Ltd - the company that builds Cardinal Ruler - holds its own ISO/IEC 27001:2022 certification, shown in the footer.

Hand your next audit a folder, not a search.

Run one real change end to end on your own origin and target pair, and keep the record it leaves behind.

Book a demo