Open-source tools for ISO 27001 controls and evidence

Identity controls in Annex A cover how users are authenticated and how access to systems is granted and withdrawn. Keycloak (Apache-2.0) fits this area by acting as a single sign-on layer, so users authenticate once with Keycloak rather than separately into each application. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can broker logins to existing OpenID Connect or SAML 2.0 identity providers, which helps when you already run a corporate directory.

• Central authentication point: applications delegate login to Keycloak, so the authentication policy is configured once and applied consistently.
• Federation to existing directories: brokered identity providers let you keep your current source of truth for identities.
• Protocol coverage: OpenID Connect, OAuth 2.0 and SAML 2.0 let you onboard both modern and legacy applications under one control point.
• Evidence kept: realm configuration, client definitions and administrative event logs can be exported and retained as proof of how authentication is set up.
• Multi-factor enforcement: confirm with the Keycloak documentation which second-factor methods and required-action settings your version supports, and test them in your own environment.

Confirm that your authentication policy, password and MFA requirements, and privileged account rules are written down and approved, because Keycloak enforces settings but does not decide what they should be.

Logging and monitoring controls ask that security-relevant events be recorded, protected and reviewed. Wazuh (GPL-2.0-only) collects and decodes logs, then compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching events become alerts written to alerts.log and alerts.json, and each alert can be mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for review in the dashboard.

• Rule-based detection: the built-in ruleset covers many common log sources, and custom rules can cover internal applications.
• Alert records: alerts.log and alerts.json give a plain, timestamped record of what fired and when.
• ATT&CK mapping: alerts carry technique references, which helps you explain detection coverage to an assessor.
• Central review: the dashboard and indexer give reviewers one place to triage alerts and document their decisions.
• Log protection: confirm how retention, access to the indexer and integrity of stored logs are configured, since those settings determine whether the logs themselves are trustworthy evidence.

The organization still decides which systems must log, how long logs are kept, who reviews alerts and how reviews are recorded. Ask your implementation partner to show a sample of reviewed alerts with the reviewer's disposition, because an alert feed without follow-up does not demonstrate that monitoring operates.

Access review controls require that access rights are checked at intervals and adjusted when they are no longer needed. midPoint (EUPL-1.2+) supports access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This counters access accumulation, where people keep rights from earlier roles, and supports segregation of duties by surfacing conflicting assignments.

• Campaign records: each campaign records who reviewed which items and what decision they made.
• Defined reviewers and deadlines: the campaign structure forces a named owner and a timeframe for each decision.
• Revocation actions: items marked for removal can be actioned in the identity system rather than left in a spreadsheet.
• Segregation of duties visibility: role assignments make conflicting combinations easier to spot during review.
• Scope limits: confirm which target systems midPoint connects to in your environment, because a review covers only the resources it can see.

The organization must decide review frequency, reviewer selection, escalation for missed reviews and how privileged access is treated. Show an assessor at least one completed campaign with its decisions and the follow-up changes, since that record is the evidence of operation.

Secrets controls concern how credentials, keys and tokens are stored, issued and revoked. OpenBao (MPL-2.0) stores secrets encrypted in one place and can generate dynamic, short-lived credentials for systems such as databases, so applications do not hold long-lived passwords. Each credential is issued with a lease that revokes it automatically on expiry, and secrets can be revoked individually or as whole trees of related credentials.

• Encrypted central store: secrets are kept in one controlled location instead of configuration files and scripts.
• Dynamic credentials: database users can be created on request with short lifetimes, reducing standing access.
• Lease-based expiry: leases give a verifiable expiry point for each issued credential.
• Bulk revocation: revoking a parent credential can remove its dependent credentials, which supports fast response to a suspected compromise.
• Audit trail: confirm which audit devices and log destinations your deployment enables, because the audit record depends on that setup.

The organization must still define rotation rules, who may request secrets, how root and unseal material is protected and how emergency access is handled. Ask your implementation partner for a dated record of a credential issuance and its automatic expiry or revocation.

Vulnerability management controls require that technical weaknesses are identified, tracked and fixed within the organization's own timeframes. Greenbone Community Edition (OpenVAS), licensed AGPL-3.0-or-later, runs the OpenVAS Scanner, which executes vulnerability tests from the Greenbone Community Feed against target systems. The feed is updated daily, and gvmd controls the scanner over the Open Scanner Protocol.

• Scheduled scans: recurring scans against defined target lists produce dated reports.
• Current test content: the daily feed update keeps vulnerability tests aligned with newly published issues.
• Report history: each scan report records findings, severities and the targets scanned, which can serve as evidence of operation.
• Credentialed scanning: confirm which authenticated scan options your edition supports, since they change the depth of findings.
• Edition boundaries: check the Greenbone documentation for features that belong to commercial editions before you rely on them in scope.

The organization must define scan scope, frequency, severity thresholds, remediation deadlines and exception approval. Show that findings move to tracked remediation and that rescans confirm closure, because a scanner report alone does not show that weaknesses were fixed.

Asset inventory controls ask that the organization knows what information and technology it holds, who owns each asset and how it is maintained. GLPI (GPL-3.0-or-later) manages an inventory through its Assets module, which covers computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10.

• Automated discovery: the GLPI Agent reports hardware and software from endpoints, reducing reliance on manual lists.
• Broad asset types: the module covers network gear, peripherals and racks, not only laptops and servers.
• Ownership fields: assets can be linked to users, locations and groups, which supports clear ownership.
• Change history: inventory updates leave a record that can show when an asset appeared or changed.
• Coverage gaps: cloud resources and SaaS applications usually need separate sources, so confirm what your deployment can and cannot discover.

The organization must define what counts as an asset, who owns it, how classification is recorded and how the inventory is reviewed. Show an assessor a reconciliation between the inventory and a sample of live systems, since an inventory that has not been compared with reality is weak evidence.

Documentation controls require policies, procedures and records that are approved, current and retrievable. XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one, which gives a clear history for policies that auditors will ask about. CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, and supports audits and compliance assessments with automatic mapping between frameworks.

• Version history in XWiki: approval and revision records can be traced through page history.
• Attribution: each change shows the author and time, which supports document control expectations.
• Framework library in CISO Assistant: the ISO 27001 library provides a starting structure for the Statement of Applicability and assessments.
• Assessment records: CISO Assistant holds assessment status and evidence links for each requirement.
• Mapping limits: automatic mappings are a convenience, so confirm each mapping against the standard and your own interpretation before relying on it.

The organization must write the policies, assign owners, approve the Statement of Applicability and decide what evidence each control requires. Ask your implementation partner to show an approved policy's version history alongside the assessment entry that cites it.