Setting up Aura Workflows for ISO and SOC audits

ISO 9001, ISO 13485, ISO 27001, and SOC 2 all rest on the same evidence question: can you produce a document and prove it was reviewed, approved, and in force on a given date? Confluence on its own does not answer that question well. Page bodies are versioned, but the metadata around a page (owner, effective date, approval state, macro values) is rendered live, so opening yesterday’s page version shows today’s metadata. Aura Workflows closes that gap. This page describes the conventions to adopt so that an ISO or SOC auditor opening a Confluence + Aura Workflows instance finds what they expect.

What auditors actually look for

Across the four schemes, the asks are surprisingly similar. ISO 9001 §7.5 (“Documented Information”) requires that documents be reviewed and approved before release and that records be “protected from unintended alterations.” ISO 13485 §4.2.4 layers on signature, approval-date, and change-reason requirements for medical-device document control, with a retention floor in §4.2.5. ISO/IEC 27001:2022 Annex A.5.33 requires records be protected for “authenticity, reliability, integrity and usability.” SOC 2’s CC8.1 puts change management for “infrastructure, data, software, and procedures” in scope: SOPs governing operational controls are themselves controlled documents.

In practice, what an auditor asks for is one of three things: the current approved version of a document; the version that was approved and in force on a specific historical date (especially under SOC 2 Type II sampling); or the audit trail showing who approved a given change and when. A document-management setup that cannot produce all three on demand is the single most common source of audit findings.

Treat the published page as the controlled artefact

The publish-flow pattern in Aura Workflows maps onto ISO 9001’s distinction between drafts and “released” documented information. The working/source page is the draft; the published copy is the released, controlled record. Every audit reference (links from a policy register, training-record citations, evidence indexes) should point at the published page, never the source. Two consequences follow.

First, restrict the working space to authors. Confluence space permissions do this; Aura Workflows sits on top. The auditor should never need to navigate to a working page, and external readers should not be able to. Second, lock published pages so they cannot be edited in place. Locking the published copy is what satisfies ISO 9001 §7.5.3’s “protected from unintended alterations” and ISO 27001 A.5.33’s integrity requirement. Without it, anyone with edit rights could silently rewrite an approved record and the audit trail breaks.

Snapshot the metadata that auditors will sample

The Metadata macro in Aura Workflows captures its value at publish time and stores it on the published page version. That property is the single most important one for audit-readiness, so it deserves to carry weight.

Concretely: place a Metadata macro for Document Owner, Effective Date, Next Review Date, and Document ID / Version on every controlled document, configured as workflow variables or workflow metadata fields. Leave the Base value on original page toggle on (the default). When the page is published, those values are frozen onto that version of the published copy. Eighteen months later, when an auditor asks “show me the version of this SOP that was effective on March 5th,” opening the corresponding published-page version through Confluence’s history will display the owner, version number, and effective date that were live then, not today’s. This is the property SOC 2 Type II sampling and ALCOA+ “Contemporaneous” both demand, and it’s what most native Confluence setups quietly fail at.

Make every approval attributable

ISO 13485 §4.2.4 and 21 CFR §11.50 want each approval bound to a named individual with a timestamp and a meaning (“review”, “approval”). SOC 2 CC8.1 calls for the same thing in different words. The approval transitions in Aura Workflows produce exactly that record, but configuration matters.

Reviewers can be configured as either named individuals or groups, and both produce attributable evidence. When a group is configured, Aura Workflows resolves the vote to the specific account that cast it and records that account in the audit trail, not the group as a whole, so an auditor opening the log sees a person’s name either way. Groups are the right choice when membership rotates (an on-call QA reviewer pool, a regional approver list); named individuals are the right choice when responsibility is fixed (the document owner, the compliance lead). Set the threshold deliberately: a single approver is fine for low-risk procedures, but anything touching financial reporting, patient safety, or production systems should require two. Capture the change reason and any impact assessment as a workflow variable on the transition that submits the draft for review; SOC 2 evidence packs explicitly include “change tickets with approval, testing, and impact assessment information,” and ISO 13485 §4.2.4 requires “a description of the change” as part of every change record.

The per-page workflow audit log is the population an SOC 2 Type II auditor will sample from. Make sure it’s exportable and that someone on the team knows how to produce it filtered by date range.

Track who acknowledged each version

Approvals certify that the named reviewers signed off before release. They do not establish that the rest of the organisation actually read the result — and several audit schemes ask for exactly that. ISO 27001 A.5.10 and A.6.3 require evidence that staff have been informed of and have acknowledged the policies that apply to them. SOC 2 CC2.2 covers internal communication of policies as a control. ISO 13485 §6.2.2 and 21 CFR Part 11 fold training and acknowledgement records into the controlled-documents apparatus.

Read confirmations produce this evidence at the page level. Enabled on a published policy, the feature shows a banner asking each viewer to Confirm, and stores a per-version acknowledgement on the page: who confirmed, when, and which version they attested to. When a new version is published, prior confirmations are flagged stale and the banner returns for those readers, prompting re-acknowledgement. That is the same control loop A.6.3 expects from a security-awareness programme: track who has acknowledged the current version, re-prompt on change, and produce the list on demand. Treat the Confirmed by list as an audit evidence artefact in its own right, the way you treat the workflow audit log for approvals.

For policies that ship to specific groups rather than the whole instance, restrict who can view the published page through Confluence space permissions. Read confirmations record who acknowledged the page; they don’t gate access to it, so the access boundary is still space permissions while the confirmation list is the evidence those gated readers attested.

Handle obsolete versions explicitly

The most common ISO 9001 finding in document control is “obsolete documents still accessible.” Translated to Confluence: an old version of a policy still findable in search, still linked from somewhere, with no clear marker that it has been superseded. The fix is a workflow state, not a deletion.

Add an Obsolete or Superseded state to the workflow on the published space, transitioned into when a replacement document is approved. The page stays (auditors need to be able to retrieve it) but it visually flags itself as no longer current, ideally via a banner macro or a status badge that the workflow flips. Combined with the metadata snapshot, this gives the auditor exactly what they want: every prior version of the document, identified, retained, and clearly distinguished from the current one.

Encode retention as workflow metadata

ISO 27001 A.5.33 and ISO 13485 §4.2.5 both require defined retention. ISO 13485’s floor is the device lifetime or two years post-release, whichever is greater; ISO 27001 leaves the schedule to the organisation but requires it be documented and applied. Encode the retention rule as a workflow metadata field on the controlled document, for example, a Retention Until date, so it travels with the page and surfaces in the metadata macro alongside the other audit-facing values. When retention expires, the workflow can transition the page into an archived state (or trigger a manual review) rather than relying on a calendar reminder no one reads.

A walkthrough that stands up to a Type II auditor

The pitch you should be able to make in a single sentence is this. Pick any date inside the audit window. We open the published page, switch to that date’s version through Confluence’s history, and the metadata macro shows the document owner, version number, and effective date that were live on that date. The workflow audit log for the same page over the audit window shows every transition, who performed it, and when.

That sentence maps directly onto SOC 2 CC8.1 (change management with approval evidence), ISO 9001 §7.5.3 (protected, retrievable documented information), ISO 27001 A.5.33 (record integrity), ALCOA+ “Original” and “Contemporaneous”, and ISO 13485 §4.2.4 (signed, dated change records). If you can deliver that walkthrough, the underlying configuration is right; if you can’t, one of the conventions on this page is missing.

For background on the building blocks referenced here, see Approvals, Variables and metadata fields, Document lifecycle and publishing, Read confirmations, and the Metadata macro.