How open source document management supports ISO 27001 documented information
If you own an ISMS and are preparing for a surveillance audit, the usual problem is not a missing policy but a policy that exists in three versions across shared drives and email attachments. ISO/IEC 27001:2022 requires documented information to be controlled, and a document management system can hold that control, but it does not make an organization compliant on its own. ISO does not certify organizations. Accredited certification bodies do that work, and they assess whether your documented information is controlled, approved, current and retrievable. The 93 Annex A controls come from the guidance in ISO/IEC 27002:2022, which explains how each control is meant to be applied. Reading that guidance alongside your own risk assessment is still your job, and no software performs it for you.
In short, a self-hosted document management system gives you three things: control over who can change and approve a document, traceability of each version and approval, and fast retrieval when an auditor asks for the evidence behind a control. Those properties matter because surveillance audits sample records from the whole cycle, not just the latest version. The ISMS design itself, meaning the scope, the risk treatment decisions and the ownership of each control, remains the organization's responsibility. Before you select a platform, confirm the current edition of the standard and the transition dates with your certification body, and write down which document types (policies, statements of applicability, risk registers, procedures and records) must sit inside the system.
Which ISO 27001 requirements a document management system must meet
This table maps the documented information needs in clause 7.5 and related Annex A organizational controls to what a document management system must do and how to configure it. Use it as a checklist when you test a platform, and confirm every control ID against your licensed copy of the standard before you rely on it.
| Requirement area | What the system must do | How to configure it and what an assessor expects |
|---|---|---|
| Document control (clause 7.5) | Hold each ISMS document in one controlled location with a unique identifier, title, owner and status | Define a document register with mandatory metadata fields; assessors look for a single authoritative copy and clear labeling of drafts |
| Version control | Keep every revision with its author, date and change summary, and block silent overwrites | Enable versioning with check-in and check-out; retain prior versions so auditors can see what was in force on a given date |
| Approval workflow | Route new and changed documents to named approvers before publication and record each decision | Configure sequential approval steps tied to roles; keep approver evidence such as timestamps and comments, not just a final status |
| Role-based access | Limit read, edit and approve rights by role and restrict confidential documents to a need-to-know group | Map roles to ISMS responsibilities; review group membership on a set schedule and log access changes |
| Review dates and ownership | Flag documents when their review date passes and notify the document owner | Store a review interval and next-review date per document; confirm the owner still exists and the document is reviewed on time |
| Retention and disposal | Keep superseded and obsolete documents for the period the organization sets, then remove or archive them under control | Document retention rules per document class; record disposal actions so you can show withdrawn versions are no longer in use |
| Policies and classification (organizational controls) | Hold information security policies and the information classification scheme as controlled documents | Store policies and classification rules with review cycles and approval records; confirm the exact control IDs in Annex A against the licensed standard |
| Audit trail and evidence retrieval | Log document actions and let an administrator export the version, approval and access history for a surveillance audit | Test a sample export before the audit; confirm the platform can produce history for a single document within a short working session |
Which open-source platforms fit ISMS document control
An ISMS needs more than a file store. Documented information must be approved, versioned, restricted and disposed of on schedule, so the platform choice depends on how much workflow control you need. The options below differ mainly in how far they go beyond capture and storage.
Nextcloud for controlled ISMS files
Nextcloud Server, licensed under AGPL-3.0, combines file storage, sharing, versioning and access controls in one self-hosted platform. For ISMS document control, it fits teams that already run it for file sharing and want one place for policies, procedures and registers with per-folder permissions and version history. Confirm whether its version retention, approval steps and retention rules meet your own requirements, and whether any approval workflow depends on add-on apps and how those apps are supported.
Alfresco Community Edition for formal records
Alfresco Community Edition is the Alfresco option in this hub and is aimed at organizations that need a content repository with versioning, metadata and permission models built in. It suits ISMS records that need structured content types and a managed document lifecycle. Before committing, confirm the Community Edition's approval, retention and disposal features against your requirements, and check the license terms and support options that apply to your deployment.
Paperless-ngx for capture and archive
Paperless-ngx is a capture and archive tool. It is strong at ingesting scans and incoming files, applying OCR and tagging them for search, which helps with evidence such as signed acknowledgments and supplier certificates. Its approval workflow is limited, so it is a poor place to manage draft policies that go through review and sign-off. Use it for the archive of finished records, and confirm how it handles versions and access restriction for your use.
BookStack for policy and procedure pages
BookStack is a wiki platform licensed under MIT. It works well for publishing policies, procedures and work instructions as readable pages with a revision history and book and shelf structure, so staff find the current version quickly. It is not a formal records system: it does not replace controlled retention, disposal of records or an evidence archive. Confirm its page history, permission model and export options against the controls you must evidence.
Outline under a source-available license
Outline is licensed under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. Internal use for your own ISMS policies is a different question from offering it to customers, so have counsel confirm your use falls within the grant. Like BookStack, it is a knowledge base rather than a records system, so pair it with a formal archive for retained evidence.
How the ISMS document lifecycle maps to system workflows
Each stage of the ISMS document lifecycle should be a distinct state in the system, because auditors test whether a document was approved before it was published and whether anyone outside the approval chain could have changed it. In an illustrative design, a draft of an access control procedure sits in a Draft state visible only to its owner. Moving it to In review notifies named reviewers, Approved requires a recorded sign-off from an approver, and Published makes the version the only one the workforce can open. Periodic review is a scheduled state change, not a memory exercise: the system flags the document when its review date passes and returns it to In review. Retirement moves a superseded version to Archived and sets a disposal date that follows the retention rule for that record type. Confirm with your certification body which documented information must be kept and for how long, because the standard leaves that decision to the organization.
Separation of duties depends on three roles that the platform must enforce, not just describe. The document owner drafts and maintains the content and cannot approve their own changes. The reviewer checks technical accuracy and is typically drawn from the control owners named in the statement of applicability. The approver, usually a manager with authority over the ISMS scope, is the only role that can move a document from Approved to Published. Map each role to a group in your identity provider rather than to individual accounts, so that a leaver or transfer changes access in one place. Check that the platform records who performed each transition, when, and the version affected, and that a user cannot hold both reviewer and approver rights on the same document. Test that rule with a deliberately conflicting account before the first surveillance audit, since a single misassigned role is a common finding.
What auditors ask to see and which component produces it
This table maps the records an ISO/IEC 27001 auditor typically samples to the component that should produce them in a self-hosted document system. Read each row as a question the auditor will ask, the artifact that answers it, and the place to check that the artifact can be pulled in minutes rather than days.
| Evidence item | What the auditor wants to confirm | Component that produces it | Where it usually fails |
|---|---|---|---|
| Document register | Every documented information item is listed with owner, status, current version and review date | Central index with metadata fields, plus a scheduled export of the register | Register kept in a spreadsheet that drifts from the repository |
| Version history | Changes are traceable, prior versions are retained and the current version is identifiable | Document versioning in the repository, with change notes required at check-in | Edits saved over files on a shared drive with no prior copy |
| Approval records | Named approver authorized the document before release, with date and evidence of the decision | Approval workflow step that stamps approver, timestamp and version approved | Approval given by email and never linked to the document |
| Access lists | Only authorized roles can read, edit or publish controlled documents, and the list matches policy | Permission report by document or folder, plus group membership export from the identity source | Group inheritance hides who can actually open a restricted folder |
| Periodic review logs | Documents are reviewed at planned intervals and obsolete items are identified | Review reminders and a log entry recorded at each review, including no-change reviews | Review dates exist but no log shows the review took place |
| Retention and disposal records | Retention periods were applied and disposal was approved and carried out as planned | Retention rules attached to document types, with a disposal log that records what was removed and who approved it | Deletions made directly on the file store leave no record |
| Audit trail exports | Who did what, when, to which document, for a sampled period | Application audit log with a documented export procedure and protected log storage | Logging turned off for admin actions or logs overwritten by rotation |
| Retrieval time in surveillance audits | The sampled records can be produced during the visit without long searches | Saved reports and a sample evidence pack per control, refreshed on a set schedule | Evidence exists but depends on one person who knows where it is kept |
What tooling alone does not satisfy
A document management system stores and timestamps evidence, but an ISO/IEC 27001 surveillance auditor tests whether the management system is real. The cards below cover the gaps that software cannot fill on its own, and each one depends on decisions the organization must make and own.
Undefined ISMS scope
The scope statement defines which processes, locations, systems and interfaces the ISMS covers. If the document system holds policies for a scope that leadership never approved, the auditor will question every record in it. Check that the scope document is approved, versioned in the same repository, and referenced by the controls that depend on it. The scope must be settled before the folder structure is designed, because folders and permissions should follow it.
Policies not followed in practice
An approved policy that staff never use creates a nonconformity, and the document system can make the gap look worse by showing a neat library of unused procedures. Auditors often sample process records against the stated procedure. Compare each controlled procedure with the workflow people actually run, and record the review date and the owner for each one. Ask who signs off changes and how exceptions are logged.
Weak access reviews
Permissions on controlled documents drift as people change roles and leave. A repository can show who has access today, but it does not decide whether that access is still justified. Schedule periodic reviews of group membership and sharing links, have a named owner approve each review, and keep the signed results. Confirm that offboarding removes access to the document system and to any share links created from it.
Retention not tied to a schedule
Retention periods for ISMS records, such as internal audit reports, risk registers and incident records, need a documented schedule that states the period and the trigger for disposal. Many open-source tools store documents indefinitely by default, which can conflict with the organization's own rules and with privacy obligations. Confirm the schedule is approved, that each document type maps to a rule, and that disposal is logged rather than silently deleted.
Missing internal audit and management review
Clause 9 of ISO/IEC 27001:2022 expects the organization to audit its own ISMS and to have top management review it at planned intervals. The document system can store the audit programme, findings and review minutes, but it cannot make those reviews happen or confirm that actions were closed. Check that each internal audit has a plan, a named auditor independent of the audited area, and tracked corrective actions with evidence of closure.
Risk decisions left to software
The organization owns the risk assessment, the risk treatment decisions and the choice of controls, including which Annex A controls apply and why. The platform only holds the evidence of those decisions. Confirm that the risk register, the Statement of Applicability and the treatment plan are approved by accountable people, and that the document system records who approved them and when.
Questions buyers ask before hiring help with ISO 27001 document control
How much effort does a document management rollout for ISO 27001 take?
Effort depends mostly on the size and state of the existing document set, not on the software itself. The main drivers are the number of documents in scope, whether they must be migrated from shared drives or wikis, how many approval paths the ISMS needs, and how many systems must be linked to the records. Ask any partner to break the work into discovery, document inventory, migration, approval and permission design, testing and handover, and to tie each phase to a written scope. A fixed-scope quote should name the document count and migration sources it assumes, so you can see what changes the price.
Can our team set up ISO 27001 document control without outside help?
Many teams can, provided they have someone who understands both the platform and the standard. The work covers deploying the system, configuring version control and approval workflows, restricting access by role, setting retention and disposal rules, and writing the procedure that explains how the system is used. Internal teams often underestimate the last item, which is what an auditor reads first. Decide honestly whether you have the platform administration skills, the time during a certification cycle, and someone to test the setup before the first surveillance audit.
What does the ISMS lead and process owners need to contribute?
The ISMS lead owns the document control procedure, the classification scheme and the decision on which documents are controlled. Process owners confirm which documents they author, who must approve them, and how long each record must be kept. Someone with administrative authority must approve permission groups, because access restriction is a management decision as much as a technical one. Expect these people to review draft configurations and sign off on the procedure. Without their time, the system may be built correctly but match nobody's actual working practice.
How does the three-year certification cycle affect the document system timeline?
Under ISO/IEC 17021-1, a management system certification cycle runs three years, and the certification body must audit at least once in every calendar year, either as a surveillance audit or as the recertification audit. That means the document system must be stable and producing evidence well before the first surveillance visit, not just installed. Plan the rollout around the audit calendar your certification body has set, and schedule a dry run where you pull version histories, approval records and access lists on request. Your certification body can confirm its own schedule and sampling approach.
Does a document management system replace the ISMS?
No. A document management system supports the ISMS by holding controlled documented information and records, but it does not decide what the risks are, which controls apply, or whether they work. The ISO/IEC 27001:2022 requirements on documented information apply to the organization's process, whatever tool stores the files. A common mistake is to treat the platform as the compliance program. Use it as the place where evidence lives, and keep the risk assessment, statement of applicability and management review under the ISMS owner's control.
Which Annex A controls does a document management system help support?
The system mainly supports the organizational and technological control areas that involve information handling, records and access. In practice, that includes controls on documented information and its retention, access restriction to information, information deletion and disposal, and logging of activity. The system does not satisfy a control on its own, because each Annex A control is an outcome the organization must demonstrate. Review the ISO/IEC 27002:2022 guidance for each control your statement of applicability relies on, and confirm with your certification body how it expects you to show evidence for each one.
How do I check that an ISO 27001 certificate is valid?
Check the certificate through the IAF CertSearch database, which ISO points to for finding accredited certificates. Since 1 January 2026, Global Accreditation Cooperation Incorporated has assumed the roles of the International Accreditation Forum and ILAC, but the search tool ISO references remains the IAF CertSearch database. Confirm the certification body is accredited, the certificate covers the right scope and sites, and the transition status matches the ISO/IEC 27001:2022 edition. This check matters when you evaluate a service provider or a supplier that claims certification.
What should I ask a partner before agreeing on a document control scope?
Ask for a written scope that lists the document types, the migration sources, the approval workflows, the roles that need access, and the retention rules. Ask who maintains the configuration after handover and how upgrades are tested. Ask what evidence the partner will hand over, such as configuration records, the procedure, and test results, and what the partner will not do, such as issuing audit reports or certifications, which only independent auditors and certification bodies do. A clear boundary between your ISMS and the partner's implementation work prevents disputes at audit time.
How a document control rollout runs in phases
The sequence takes controlled documents from an unmanaged set of files to a document system where each ISO 27001 document has an owner, an approved version, a restricted audience and a retention rule. Each phase produces an artifact that the next phase depends on, so the audit trail is built as the work happens rather than reconstructed before a surveillance visit.
Define scope and inventory documented information
Start by agreeing which parts of the information security management system sit in the document system, which is usually the policies, procedures, risk treatment records, statements of applicability, internal audit reports and management review minutes. Locate where these documents live today, including shared drives, wikis, email attachments and personal folders. The security lead, the ISMS owner and the document owners sign off the inventory. It is done when every document in scope has a named owner and a current location, and anything out of scope is recorded with a reason.
Design classification and metadata
Define the document types, the status values (draft, in review, approved, withdrawn), the metadata each record must carry, such as owner, version, approver, review date and linked Annex A control, and the classification levels that drive access. Map each document type to a retention period and disposal action set by the organization. The output is a written document control procedure and a metadata schema that the platform configuration will implement. Confirm the design against the ISMS documentation requirements in ISO/IEC 27001:2022 with your own certification body's expectations, since interpretation can vary.
Configure the platform and access model
Build the chosen platform to match the design: document types, metadata fields, status workflow, groups tied to roles rather than individuals, and read and edit permissions per classification level. Enable version history, and confirm that the audit log records uploads, edits, approvals, permission changes and deletions with user identity and timestamp. Test these settings in a non-production instance first. It is done when a test user without rights cannot open a restricted document and every test action appears in the log.
Migrate controlled documents with version history
Move the in-scope documents in batches, starting with the most-used controlled set. For each document, carry over the latest approved version and, where it is available and useful as evidence, earlier versions with their dates. Record a mapping from the old location to the new record so auditors can follow the trail. Remove or lock the legacy copies so that two current versions cannot coexist. It is done when a reconciliation report shows every in-scope document present once, with an owner and a single current version.
Run a pilot with approvers
Select one or two document families, such as the information security policy and the access control procedure, and run them through the full cycle: draft, review, approval, publication and scheduled review. Approvers should work in the real workflow and report where it is slow, confusing or unclear about who may approve what. Adjust the workflow and the permission groups based on that feedback. It is done when a document has moved through the complete cycle with the approval recorded in the system, and the approvers confirm the process is workable.
Go live and retire legacy storage
Announce the cutover date, publish the document control procedure and short guidance for authors and readers, and move the remaining in-scope documents. Make the legacy locations read-only with a pointer to the new home, and assign a named owner for the platform who handles access requests and changes. Keep a record of the cutover decisions. It is done when all in-scope documents are in the system, the legacy locations are locked, and the owner of the platform has been named in the ISMS documentation.
Complete the first internal audit of the system
Have someone independent of the document owners test the system against the procedure: sample documents for correct status and version, check that approvals are recorded, confirm access matches the classification rules, check that a withdrawn document cannot be edited, and verify that the audit log can produce the history for a sampled document. Record nonconformities and corrective actions in the ISMS record set. It is done when the internal audit report is filed and any corrective actions have owners and due dates, which gives the first evidence pack for the certification body's surveillance audit.
How DeployOpen scopes, builds and supports ISMS document control
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so document control for your ISMS is built around your scope and your evidence needs. Each engagement starts with a written scope agreed before work begins.
How we scope
- Map which ISMS documents, policies, procedures and records sit under document control and who owns each one.
- Agree the approval workflow, version rules and access groups for each document class in writing before build starts.
- Define the retention and disposal rules, and the evidence pack an internal auditor or certification body would request.
How we build
- Deploy the chosen document platform in your cloud accounts, data center or air-gapped network, with access tied to your identity source.
- Configure version history, review and approval steps, and restricted folders that match the access rules agreed in scope.
- Test permissions, audit logging and retention behavior against the written scope before any documents are migrated.
How we hand over
- Deliver configuration records, permission matrices and runbooks that your ISMS owner can review and maintain.
- Document how to pull version history, approval records and access logs quickly when a surveillance audit requests them.
- Walk your team through backup, restore and disposal procedures, and confirm which steps remain your responsibility.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Plan platform upgrades and security patch cycles so the document system stays supported and its evidence stays intact.
- Ask your certification body or auditor which evidence they accept, since DeployOpen prepares controls and records but does not issue certifications.
