Confluence continuity work should not begin with panic. It should begin with a repeatable export path that produces customer-controlled Markdown, preserves enough structure to stay useful, and can be refreshed on demand.
That is the difference between having a backup artifact somewhere and having a continuity copy that operators can actually use. When a team needs to recover documentation access, respond to an ISO 27001 surveillance audit, evidence a NIS 2 incident timeline, satisfy an SOC 2 availability test, seed a new portal, or hand content to AI pipelines, the copy has to be readable, navigable, and current.
Continuity is no longer optional for most operators. NIS 2 makes it an Article 21 cybersecurity risk-management duty for thousands of essential and important entities. ISO/IEC 27001:2022 added control A.5.30 specifically for ICT readiness for business continuity. SOC 2 trust services criteria require evidence of backup design and recovery testing. And ISO 9001 has always required that documented information be controlled, current, and retrievable. A continuity copy in Git is one of the cleanest ways to produce that evidence without adding a new platform to the audit scope.
Continuity copies are not the same as backups
Many teams say they have a documentation backup when what they really have is an opaque archive or a one-time export no one trusts.
A usable continuity copy has different requirements:
- it must be readable without returning to Confluence
- it must preserve hierarchy well enough to behave like a documentation estate
- it must be refreshable without rebuilding the process from scratch
- it must be versionable so teams can prove what changed and when
- it must be portable enough to feed publishing, retention, and AI workflows
Continuity is operational. If the copy cannot be inspected quickly, reviewed in Git, and regenerated on a schedule, it is not solving the continuity problem.
What a usable continuity copy has to preserve
Teams often focus on file creation and overlook semantic preservation. That is the wrong optimization.
For continuity work, the copy should keep:
- headings and outline structure
- internal links rewritten into the local estate
- code blocks in stable fenced Markdown
- tables that are still reviewable in Git
- images and referenced media with usable paths
- enough metadata to support audit, indexing, and downstream automation
The reason this matters is simple: continuity events rarely happen at a convenient time. If operators have to re-clean the export before they can use it, the copy is already failing when it matters most.
Why Git improves continuity instead of complicating it
Some teams treat Git as an engineering convenience rather than a continuity control. That misses the point.
Git gives continuity workflows several practical advantages:
- every refresh produces a diff instead of an uninspectable blob
- teams can prove cadence and change history to auditors or stakeholders
- a known-good copy can be restored instantly from a tagged commit
- the same Markdown tree can feed static sites, search indexes, and retrieval pipelines
Git does not fix a bad export. But when the export is deterministic and portable, Git turns continuity from a manual emergency task into a governed operating process.
Recommended workflow for a repeatable continuity estate
The safest pattern is to validate the environment, inspect the scope, export to a Git-owned directory, and then refresh on a schedule.
1. Validate the workstation before the first export
Start by checking credentials, license state, and workstation health.
acs2md doctor This is a cheap check that catches broken assumptions before a real continuity run is attempted.
2. Inspect the target space and page tree
Do not schedule a sync job against a space you have not inspected.
acs2md space pages by-key OPS That inventory step makes it easier to confirm what the continuity copy should contain and whether the hierarchy matches what downstream consumers expect.
3. Export into a Git-owned continuity directory
When the goal is a reusable estate, the output path should already live inside a repository or a directory intended to be committed.
acs2md space convert by-key OPS --output-dir ./continuity/ops --rewrite-links --sync The important part is not only that the export succeeds. It is that the copy lands in a durable place with rewritten local links and a refresh mechanism that can be repeated.
4. Commit the resulting tree and review diffs
Once the copy exists, treat it like any other governed content change.
git add continuity/ops
git commit -m "Refresh OPS continuity copy from Confluence" That step creates an audit trail and makes it possible to compare one continuity snapshot to the next.
5. Repeat on a schedule instead of waiting for an incident
Continuity workflows fail when they depend on memory. A copy that was only generated once six months ago is not a continuity strategy.
Use a scheduler, CI job, or internal automation to run the refresh path on a cadence that matches operational risk.
The role of stable paths and rewritten links
Continuity copies become immediately more useful when local paths behave predictably.
If an incident forces a team to work from the copy, they should not discover that every internal reference still points back to Confluence. Local link rewriting matters because it turns the export into a self-contained estate rather than a disconnected file dump.
Stable output paths also matter for:
- site generation
- search indexing
- retention workflows
- downstream AI ingestion
- incident handoff between teams
Predictability is part of recoverability.
How to validate a continuity copy before you trust it
Before declaring the workflow done, inspect the copy the way an operator would inspect it under pressure.
Check at least the following:
- The top-level structure mirrors the expected space hierarchy.
- Sample internal links resolve inside the exported tree.
- Code blocks remain readable and language-aware.
- Tables remain understandable in plain Markdown.
- Deleted or renamed pages show up as meaningful diffs on the next sync.
- Media references and important diagrams still resolve.
Validation should happen before a real continuity event forces the issue.
Mapping continuity copies to ISO, NIS 2, and SOC 2 controls
Auditors do not accept “we have a backup somewhere” as evidence. They look for a documented, repeatable, testable process that links a control objective to a concrete artifact. A Git-tracked continuity copy produced by acs2md lines up cleanly with the most common framework requirements:
| Framework | Control or clause | What the continuity copy provides |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.30 ICT readiness for business continuity | A current, restorable Markdown estate that can be tested without depending on Confluence availability. |
| ISO/IEC 27001:2022 | A.5.33 Protection of records | Versioned Git history proves who changed what, when, and how the record evolved. |
| ISO/IEC 27001:2022 | A.8.13 Information backup | Repeatable export schedule, deterministic output, and a state file to detect drift. |
| ISO/IEC 27017:2015 | CLD.12.1.5 Administrator’s operational security | Read-only GET access against Confluence Cloud, recorded in CI logs, suitable for cloud-customer evidence. |
| ISO 9001:2015 | Clause 7.5 Documented information | Customer-controlled Markdown that can be reviewed, distributed, and superseded outside a vendor portal. |
| NIS 2 (Directive 2022/2555) | Article 21(2)(c) Business continuity, backup management, crisis management | Refreshable continuity copy with timestamped commits that can support incident reconstruction and the 24/72-hour notification flow. |
| SOC 2 (TSC 2017) | A1.2 / A1.3 Availability — backup processes and recovery testing | Tagged commits act as restore points; a periodic --sync job is the documented recovery procedure. |
The point is not to claim the tool “makes you compliant”. No tool does. The point is that the artifact acs2md produces is the kind of artifact each of these frameworks asks for: an inspectable, dated, restorable copy of the documented information that runs your business.
If your security or quality program relies on Confluence as a system of record, a continuity copy is the difference between a clause you can evidence in five minutes and a clause that turns into an audit finding.
What teams usually get wrong
The most common failure patterns are operational, not theoretical.
- generating one export and never refreshing it
- keeping only proprietary archives that are hard to inspect
- skipping link rewriting and local path validation
- failing to store the copy in Git or another auditable system
- assuming continuity and migration are the same thing every time
Migration and continuity overlap, but the continuity requirement is narrower and more unforgiving: the copy must still be usable when the original system is unavailable or inconvenient.
When acs2md is the right fit
acs2md is the right tool when the unit of work is the space, not the single page.
That usually means:
- continuity estates for a whole documentation space
- governed backup workflows with repeatable refreshes
- Git-native copies used for audit, recovery, or publication
- Markdown trees that need rewritten links and preserved hierarchy
If the requirement starts with one page, acp2md is usually the better first step. If the requirement is continuity at space scale, acs2md is where the workflow belongs.
Final take
The point of a continuity copy is not to prove that export happened once. The point is to create a current, inspectable, repeatable Markdown estate that can survive migration pressure, audit pressure, and platform disruption — and that can be shown to an ISO 27001, ISO 27017, NIS 2, or SOC 2 assessor without scrambling.
With acs2md, a disciplined export path, and Git-based review, teams can keep Confluence continuity copies current instead of discovering too late that their backup story was only nominal. Compare the acs2md plans in our store when you are ready to make this part of your control evidence.
Discuss this article
Comments are ready for Giscus, but the public repository and category settings have not been added yet.