Open source project management for ISO 27001: how A.5.8 changes project work
Control A.5.8 asks that information security be integrated into project management, so that security risks tied to projects and their deliverables are addressed throughout the project life cycle. For an ISMS owner, the practical question is where that integration lives. A security policy states the intent, but it does not reach a project team unless the project tool carries the requirement into planning, scheduling and sign-off. A project management platform such as OpenProject can hold that structure, using work packages as the unit where a security requirement or risk is recorded, owned and closed. The tool supports the control, but it does not make an organization compliant by itself. Compliance depends on whether the organization's own process actually uses the structure. A.5.8 sits in the organizational controls theme (clause 5) of ISO/IEC 27001:2022 Annex A. It merges two controls from the 2013 edition, A.6.1.5 Information security in project management and A.14.1.1 Information security requirements analysis and specification, so an assessor will expect both the risk and the requirements angle to be visible in project records. The implementation guidance for the control is in ISO/IEC 27002:2022, which the organization should read alongside the standard when it defines its own project steps. Certification is not issued by DeployOpen or by ISO. Accredited certification bodies perform the audit and decide whether the ISMS meets the standard, so the reader should confirm early which body will assess the scope and what evidence it expects. Before configuring anything, the ISMS owner should decide three things: which project types fall inside the ISMS scope, which roles own security requirements in each project, and which records will prove the control operated. Those decisions shape the work package types, custom fields and project templates that come later. Ask the implementation partner to show how a sample project would record a security requirement, a risk and its treatment, and who approved each. The answer will show whether the design fits the organization's ISMS or only looks tidy in a demo.
Mapping A.5.8 and related controls to OpenProject configuration
This table maps the information security in project management control and its closely related Annex A controls to the OpenProject configuration that supports them. Read each row as a requirement, what the project function must do, and where to start in OpenProject, then confirm exact feature names against the documentation for the version you install. The main takeaway is that security becomes evidence only when it is recorded in the same work items, workflows and permissions the project already uses.
| Requirement | What the project function must do | How to configure OpenProject |
|---|---|---|
| A.5.8: security requirements at initiation | Capture security requirements for each project as work packages before design or build starts, so they are scheduled and owned like other deliverables. | Create a security requirements work package type or a dedicated parent work package per project. Confirm the current work package type options in your installed version. |
| A.5.8: security risks linked to deliverables | Log project security risks and tie each one to the deliverable it affects, so risks move through the life cycle with the work. | Use risk work items with relation links to affected deliverables. Confirm which relation types your edition offers and whether risk registers need custom fields. |
| Secure development and project templates (A.5.8, A.8.25) | Start every new project from a template that already contains mandatory security review and sign-off steps, so teams cannot skip them by accident. | Build a project template with security review, threat assessment and sign-off work packages. Confirm how templates are copied and maintained in your version. |
| Classification and risk ownership | Record the data classification of each project and name a risk owner who is accountable for each security item. | Add custom fields for classification and risk owner on the project or work package. Confirm field types and whether they can be made required. |
| Closure gated by security acceptance | Prevent a deliverable from closing until security acceptance is recorded by an authorized reviewer. | Configure status workflows so that closing statuses are restricted by role, and document the acceptance step in a sign-off work package. Test the workflow before go-live. |
| Restricted change rights for security items | Ensure only authorized security staff can change security requirements, risk status and acceptance records. | Set roles and permissions so that security work packages can be edited by named groups only. Confirm the permission scope available in your edition and review it on a set schedule. |
| Life cycle reviews via milestones and dashboards | Show security review points across the project timeline so reviews are visible to sponsors and assessors. | Place security review milestones in the Gantt chart and build dashboards or queries that list open security items per project. Confirm which views are included in your edition. |
| Supplier deliverables (A.8.30) | Track outsourced or supplier deliverables with the same security fields, reviews and acceptance steps as internal work. | Use the same work package types, custom fields and workflows for supplier deliverables, and assign supplier contacts through user accounts or groups. Confirm external user licensing and access limits with the vendor. |
Which open-source project tools fit an ISMS project process
Annex A control 5.8 asks that security run through every project, so the tool has to hold requirements, risk entries and approvals as first-class items. The cards below cover the primary candidate, the alternatives, and the adjacent systems that hold ITSM records and controlled documents.
OpenProject as the primary fit
OpenProject is GPL-3.0 licensed, and its free Community edition includes work packages, Gantt charts, agile boards, time tracking and dashboards. Security requirements and risk items can be modeled as work package types, with templates that every new project starts from. The Enterprise on-premises edition adds single sign-on (SAML, OIDC, CAS, Kerberos, Okta), LDAP group synchronization and custom branding, priced per named user per month. Confirm which edition your identity setup requires before you commit.
Plane for agile delivery teams
Plane is AGPL-3.0 licensed and suits teams that run sprints and cycles and want security tasks to sit beside feature work. Its fit for ISMS work depends on whether you need custom work item types, approval steps and reporting on risk items. Confirm which LDAP and SSO options are available in the edition you plan to deploy, since these depend on edition. Test the dedicated templates before you rely on them for control evidence.
Redmine for plugin-based workflows
Redmine suits organizations that already run plugin-based workflows and want security-specific fields, approvals and issue categories added through plugins. Each plugin becomes part of your change and patch process, so list them, their maintainers and their upgrade path before rollout. Confirm which plugins provide the risk register, approval and audit views you need, and which of them support the SSO model you require.
ITSM tools for change and incident records
GLPI (GPL-3.0) and iTop (AGPL-3.0) cover ITIL service management, change records and configuration items. For ISMS projects, link a change or asset record to the project work package that introduced it, so reviewers can trace a deployment back to its security requirements. Confirm whether the ITSM and project tools can exchange records through an API or only through manual linking.
Document systems for controlled records
Nextcloud (AGPL-3.0) or BookStack (MIT) can hold controlled documents such as risk assessments, data flow diagrams and approved policies. Link each document from the relevant work package rather than copying it into the ticket, so the version the reviewer sees is the controlled one. Confirm how each platform handles versioning, access rights and review dates before it becomes the document source of record.
Configuring OpenProject so project records can be audited
The evidence trail for A.5.8 is only as good as the platform underneath it, so the first configuration decisions are about the install itself. OpenProject supports Docker-based installation, which the documentation recommends, as well as .deb and .rpm packages on supported 64-bit Linux releases, including Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Choose one method, confirm the exact release against the current system requirements page, and document the version you deployed, because the audit questions about who changed a work package and under which software build depend on that record. Use PostgreSQL 16 or later, since that is the officially supported database version from OpenProject 16.0.0, and make sure the pg_trgm, btree_gist and unaccent extensions are installed before go-live. For sizing, the vendor's guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Confirm these figures against your own user count and peak project load during the design phase.
Named accounts matter more to an auditor than any single setting. Single sign-on (SAML, OIDC, CAS, Kerberos or Okta) and LDAP group synchronization are listed among OpenProject Enterprise features, so confirm with the vendor which edition covers the identity methods your directory uses before you plan the access model. Map project roles to directory groups so that leavers are removed centrally and no shared project accounts exist. Where controlled documents such as risk registers, security requirement specifications or test evidence live in Nextcloud, the OpenProject Nextcloud integration can link those files to work packages, so the reviewer can trace a requirement to its source document. Keep the link targets in the file system or in Nextcloud's own access controls, not in free-text comments that anyone can edit.
Two operational decisions complete the picture. First, the audit logs produced by OpenProject, the reverse proxy and the host must be forwarded to storage that the project team cannot alter, and the database must be backed up on a schedule that you test by restoring to a separate environment. Second, retention periods for these records are set by your information security policy, your contractual obligations and any legal requirements that apply to your sector, not by the tool. Ask your implementation partner which logs OpenProject writes by default, how long the containers keep them, and what must be exported to your own retention system. Confirm the retention schedule with your compliance lead and your external auditor before you rely on the platform as evidence.
Evidence auditors ask for and which component produces it
This table maps the records an assessor is likely to request for A.5.8 to the part of the setup that produces each one. Read the third column as a starting point: OpenProject generates much of the project-side evidence, while the operations runbook and the organization's own procedures produce the rest. The auditor decides whether the evidence is sufficient, and the organization must sample and explain it.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Documented project security requirements | Security requirements are defined for each project, typically as standard fields or required sections in work package templates. | OpenProject work package types and templates, backed by a written project security procedure |
| Risk register entries linked to deliverables | Information security risks are identified and tied to the specific work packages or deliverables they affect. | OpenProject work packages with risk entries or linked work items, plus a risk register owned by the project team |
| Review and approval records | Security reviews happened at defined gates and were signed off by the right roles before work progressed. | OpenProject workflow status transitions and comment history on work packages |
| Role and access lists | Who could view, edit and approve project security items, and how that access was granted. | OpenProject roles and permissions, with groups synchronized from the directory where SSO or LDAP sync is in use (Enterprise feature to confirm) |
| Supplier and outsourced deliverable records | Security requirements passed to external suppliers and checks made on their deliverables, as also covered by A.8.30. | OpenProject work packages assigned to external users, plus contract and acceptance records held outside the tool |
| Change history and timestamps | When security-relevant fields, statuses and scope changed, and by whom. | OpenProject activity log and journals on work packages, retained according to the instance configuration and backup policy |
| Backup and restore test records | The project data can be recovered, and the organization has tested it. | Operations runbook and test logs maintained by the platform team; the backup tooling alone does not prove a restore worked |
| Management review inputs | Management sees the status of security items across projects so it can review them. | OpenProject dashboards and portfolio reports, exported or presented as part of the management review pack |
What project tooling alone does not satisfy
A project tool can carry security requirements into daily delivery, but it cannot write the ISMS, decide risk criteria or enforce its own use. The cards below separate what OpenProject configuration covers from what must be governed, documented and verified outside the tool before an ISO 27001 assessment.
Methodology and policy stay outside
The risk assessment methodology, the information security policy and the criteria for accepting risk are management decisions. A work package template can ask for a risk rating, but it cannot define how that rating is calculated or who signs off on it. Check that these documents exist, are approved and are referenced from the project template before you rely on the tool as evidence.
Templates only work if teams use them
A security review step in a template protects a project only when project managers create work packages from it and do not bypass it. Inspect a sample of live projects against the template, and define who can create projects outside the standard workflow. Without that check, the tool will show a process that teams have quietly skipped.
Scope, assets and treatment plan sit elsewhere
The ISMS scope, the asset register and the risk treatment plan are governed records that span the whole organization, not the lifecycle of one project. Decide which system holds each record, how a project links to it, and how changes flow back. Auditors will look for the authoritative register, not a copy inside a task list.
Legacy Jira security records need testing
The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x only, not Jira Cloud, and it is in beta with documentation advising use only in test setups. Security comments, attachments and custom fields from past projects may not carry over. Run a test migration, compare a sample of security-relevant items field by field, and document what was lost.
Enterprise features must be bought and configured
Single sign-on, LDAP group synchronization and custom branding are listed among OpenProject Enterprise features, so they are not part of the free Community edition. Access control for security-relevant projects depends on these being purchased, deployed and tested, not assumed. Confirm the edition, the user count and the identity provider integration in the written scope.
Certification needs an accredited body and mapped controls
Only an accredited certification body can certify an ISMS, and ISO itself does not certify organizations. The 2013 certificates had to expire or be withdrawn by 31 October 2025 under IAF MD 26:2023, so any organization working from older control numbering must map its project controls to A.5.8 and the 2022 Annex A. Ask your certification body which evidence it expects for project security.
How much work does an A.5.8 project process take, and what do we do ourselves?
Can our own team configure OpenProject for A.5.8 without an implementation partner?
Yes, a team with administration skills can configure work package types, custom fields, project templates and roles in OpenProject without a partner, and the Community edition is free to install and run. The harder part is the design work: deciding which security questions every project must answer, who signs them off, and how that evidence is kept. Most organizations find that the technology is the easy part and the process decisions take longer. Confirm internally whether you have an owner for the template design and a person who can run the installation, upgrades and backups over time.
What drives the effort of an A.5.8 project process up or down?
Effort rises with the number of active projects and portfolios, the number of distinct project types (for example, internal change, supplier delivery and customer-facing build), and whether existing data must be moved. It also rises when SSO and LDAP group sync are required, because those features sit in OpenProject Enterprise editions and need identity integration work. Supplier and outsourced projects add review steps tied to A.5.19 and A.8.30. Confirm these inputs with your ISMS manager before asking for a quote, since each one changes the scope.
Does a Jira or Redmine migration change the A.5.8 effort?
Yes, because historical work packages and their security fields have to be mapped before the old data is retired. The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and its documentation advises using it only in test setups while it is in beta. Redmine data needs its own mapping review. Plan for a reconciliation step in which you decide which closed projects need their security records carried over and which can be archived. Ask any partner to show how they will handle that decision.
What recurring work does an A.5.8 project process create?
The recurring work falls into four areas: platform upgrades, backups and restore tests, periodic review of project templates and checklists, and evidence collection for audits. OpenProject releases new versions regularly, for example 17.9.0 on September 30, 2026 and 17.9.2 on October 15, 2026, so someone must schedule and test upgrades. Accredited certification bodies work on a three-year cycle under ISO/IEC 17021-1 with at least one audit in every calendar year, so the evidence must be kept current all year. Confirm with your certification body how often it will sample project records.
What do process owners, the ISMS manager and IT need to provide?
Each group has a distinct job. Process owners define the project types and say which security questions apply to each. The ISMS manager sets the risk criteria, approves the templates and confirms the link to the risk register and statement of applicability. The security team reviews high-risk projects and supplier deliverables. IT owns hosting, the database, identity integration, backups and patching. Agree these responsibilities in writing before configuration starts, because gaps between these groups are the most common source of delay.
Can an implementation partner verify that our A.5.8 controls are designed correctly?
A partner can help design the project templates, configure the workflow, document the control design and prepare evidence for your assessment, which is the readiness work DeployOpen performs. It cannot issue an audit opinion or certify your organization, because certification is performed by an accredited certification body. ISO itself does not certify organizations. Ask any partner to show how they map the design to the control and to the ISO/IEC 27002 guidance, and to state clearly which parts remain your responsibility.
What should we ask for in a written quote for this work?
Ask for a fixed scope that lists the projects and project types in scope, the editions required and the reason for each, the identity integrations, the migration sources and the volume of data, and the hosting environment. Request the deliverables in writing, including template designs, configuration records, runbooks for backup and upgrade, training, and the evidence pack. Ask which items are one-time and which are recurring, what a retainer covers, and what the client must supply. Confirm the OpenProject edition and its per-user licensing separately, since Enterprise pricing is set per named user per month.
A phased rollout that keeps active projects running
Start with the ISMS scope, not the software. Before anything is configured, confirm which projects, programs and deliverables fall inside the scope of your information security management system, and inventory where their records already live: spreadsheets, Jira or other trackers, shared drives and mailboxes. For each source, record the project owner, the open risks and the security approvals already given. This inventory tells you which projects must carry A.5.8 evidence from day one and which can wait. If you are moving from Jira, check the OpenProject Jira Migrator against your Jira deployment before any security history is moved. The migrator documentation covers Jira Data Center 10.x and 11.x, not Jira Cloud, and it is in beta with guidance to use it only in test setups. Confirm with the vendor and in a test instance whether attachments, comments, history and custom fields that hold security approvals come across intact, and keep the original system available as the record of truth until you have verified the copy.
Next, build the security structure in a pilot. Create a project template that holds the security requirements, risk identification and review gates that your A.5.8 procedure requires, and define work package types for security items such as requirement, risk treatment, security review and acceptance. Give each type its own workflow so that a security review cannot be closed by the same role that created it. Run this on one or two active projects with real deliverables, not a sandbox, and collect what the project managers and security reviewers actually struggle with. Expect to adjust statuses, custom fields and the template at least once. Only after the pilot has produced a stable template should you copy it to other projects. Confirm with your certification body how it expects the pilot evidence to be presented, since the pilot is itself a record of how the process was tested.
Roll out in waves with identity controlled centrally. Connect single sign-on and directory group synchronization before users are onboarded in bulk, so that project roles follow your directory groups rather than manual assignments. Check the edition requirements for SAML, OIDC, LDAP group synchronization and custom branding in the OpenProject pricing page before you commit, because those features sit in Enterprise plans. Keep an evidence pack for every project: the approved template version, the risk register extract, the security review records, the access list with its directory groups, and the sign-off dates. Store that pack in a location that the project and the audit team can both reach, and review it at each stage gate. The pack is what makes A.5.8 demonstrable at audit, so treat its completeness as a rollout exit criterion rather than a clean-up task for later.
How DeployOpen scopes and supports ISO 27001 project controls
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For ISO 27001 project controls, we set up the project management platform so that security requirements and risk checks are part of how projects are planned, built and handed over, and we prepare the evidence your internal audit and certification body will ask to see.
How we scope
- Inventory which projects, deliverables and suppliers fall inside your ISMS and which teams own them.
- Agree which security requirement and risk work packages, templates and review gates each project type must carry.
- Confirm the edition, single sign-on and hosting needs in writing before any build work starts, under a fixed-scope agreement.
How we build
- Configure OpenProject work package types, statuses and custom fields for security requirements, risk entries and sign-off.
- Build project templates that create the Annex A 5.8 checklist automatically at project start, with named owners.
- Test access roles, permissions and audit history so that security records cannot be edited silently by project members.
How we hand over
- Document the configured workflow, template library, role matrix and review procedure in a handover pack your team can maintain.
- Provide a mapping from each template step to the Annex A 5.8 intent, so auditors can trace project controls to the ISMS.
- Train project managers, security reviewers and PMO staff on how to raise, track and close security work packages.
How we support
- Offer ongoing support, upgrades and periodic review of templates as your ISMS and project portfolio change, through a retainer.
- Plan OpenProject version upgrades and database maintenance as tested changes, with rollback steps documented.
- Ask your certification body and internal auditors to confirm which evidence they need, since DeployOpen prepares evidence but does not issue audit reports or certifications.
