Step-by-Step Guide: Setting Up an ISMS in Kordon

A general guide to building an information security management system (ISMS) on the Kordon.app platform, based on the requirements of ISO/IEC 27001:2022.

Introduction

This guide is for anyone who wants to build a working information security management system (ISMS) for their organisation using Kordon. It suits both a first-time ISO 27001 implementer and a security manager migrating an existing programme into Kordon.

A note before you start. This guide describes each step through the Kordon user interface, since that is the clearest way to build an ISMS for most readers. However, many of the steps described here, especially the initial entry of business processes, assets, vendors, risks, and controls, can also be done through the Kordon API in bulk, either as a CSV-based bulk import or with the help of an AI agent. This is especially useful when entering large volumes of data or migrating an existing ISMS into Kordon. See Chapter 13 for details.

Kordon’s starting point is simple, but important: an ISMS is not a stack of documents that gets written once and put on a shelf. It is a living system in which risks drive the choice of controls, and controls, along with risks, vendors, assets, and findings, are brought to life through recurring tasks. Tasks are not tied only to controls: the same mechanism carries risk acceptance decisions, vendor reviews, asset inventories, and finding remediation. Completing a task automatically creates evidence that simultaneously confirms both risk mitigation and compliance with the chosen framework (e.g. ISO 27001). The same piece of evidence serves multiple purposes at once. This is exactly why every object in Kordon (requirements, controls, risks, assets, vendors, business processes, findings, tasks) can be connected to every other.

This guide assumes your organisation’s Kordon account already exists and that the relevant frameworks (e.g. ISO 27001) have already been added to it. The guide starts from that point.

By the end of this guide, you will have:

An ISO 27001-compliant Statement of Applicability (SoA) foundation in Kordon
An information security policy and clear ownership documented directly in Kordon as a control
A documented business context (business processes, assets, vendors)
A risk assessment methodology and a populated risk register
A set of controls linked to both risks and requirements
A working task cycle that continuously generates evidence
Readiness for an internal audit, a management review, and a certification audit

Two possible paths. Kordon lets you build an ISMS from two directions. This guide covers both, but by default follows the path from context (business processes → risks → controls) to requirement coverage:

Starting from context: document business processes, assets, and vendors → identify risks → choose controls → link them to requirements.
Starting from compliance: review the ISO 27001 requirements → set applicability → create controls to cover the requirements → retroactively link them to risks and assets.

1. Information Security Policy and Ownership (ISO Clause 4–5: context and leadership)

Create the information security policy as a control in Kordon. In a well-run organisation, this policy covers:
- The ISMS scope: which parts of the organisation, locations, systems, and services fall under the ISMS
- A stakeholder map: customers, regulators, owners, partners, whose requirements for information security influence later applicability decisions
- A statement of management commitment
This policy control is the ISMS’s formal foundation document. Link it to the relevant ISO 27001 requirements it directly covers (e.g. general requirements that apply to the organisation as a whole), just like any other control.
Add users and assign each one a role that matches their actual responsibility on the platform.
For larger teams: set up SSO (Google Workspace, Microsoft Entra, or another SAML 2.0 SSO provider) and, if needed, automatic user provisioning via SCIM, so user management doesn’t become extra manual work.
Create user groups by area (e.g. “IT team”, “Internal audit”) to allow tasks to be assigned to groups/roles.

2. Requirement Applicability

Go through every requirement in the framework and set its applicability for each one: applicable or not applicable, plus a justification. This step looks formal, but it’s the foundation for everything that follows: it determines which requirements’ coverage by controls and risks gets tracked at all.
Keep this first pass broad (most ISO 27001 Annex A requirements are applicable to most organisations). You can refine the applicability justifications later, once risks and controls have been documented (see Chapter 7).

3. Business Context: Business Processes, Assets, Vendors

This is the step where the ISMS starts to reflect how the organisation actually operates, rather than a generic template structure.

Document business processes: the organisation’s critical activities (e.g. “delivering service to customers”, “payroll”).
Enter assets and link them to the business processes they support. For your more important assets, it’s worth adding a recurring inventory or review task right away (see Chapter 6).
Enter vendors, including contracts and deadlines, and link them to the business processes and assets they have access to. Vendor-linked tasks work well both for the security assessment done during onboarding and for periodic reviews and offboarding-related activities (e.g. revoking access) (see Chapter 6).
Watch the Health indicator (Healthy / At Risk / Unmanaged) on every business process, asset, and vendor. It gives you an immediate visual sense of what’s already under control and what isn’t. New objects default to “Unmanaged” until risks, controls, or tasks are added to them.

4. Risk Management

Risk settings and assessment: an impact/probability scale (e.g. 1–5) applied consistently throughout. Document the risk assessment methodology as a control in Kordon, or as part of the information security policy created in Chapter 1.
Enter risks into Kordon with their assessed impact and probability.
Link risks to the assets, vendors, and business processes they threaten, so you get visibility into which risk affects which part of the business.
Link risks directly to requirements when a risk is the reason a specific ISO 27001 requirement applies to the organisation. This connection later becomes the basis for the SoA justifications (see Chapter 7).
The risk register in Kordon is not a static list. If a control mitigating a risk moves to the “Failing” state, this is immediately reflected in the risk’s actual level (see Chapter 5).
When a risk is accepted, link a recurring review task to it that requires the decision to be periodically reconfirmed (see Chapter 6). An accepted risk isn’t a one-off decision, it’s a position that needs to be revisited regularly.

5. Controls

A control in Kordon always serves at least one of two purposes: risk mitigation and/or compliance, often both at once. Every control also has a type: policy, procedure, or technical control. Choose the type based on whether it’s a written rule, a described process, or a technical safeguard (e.g. a firewall rule, encryption).

Choose a starting point: use Kordon’s ready-made templates (controls that have already passed audits) or build a control from scratch.
Write the control description specifically, not generically:
- Name the actual mechanism (tool, process), not “in accordance with policy”.
- Name the responsible role or team.
- If the control is automated, say so and name the system that enforces it.
- Don’t write the control description so that it merely restates the linked requirement’s text. The control description must say what is actually done.
Link the control to the risks it mitigates. Note how much the control reduces impact and/or probability.
Link the control to the requirements it covers. One control can cover multiple requirements at once, saving duplicated work.
Link the control, where relevant, to the assets, vendors, or business processes it protects or operates in the context of.
All policies, procedures, and rules also belong under controls. The information security policy created in Chapter 1 and the risk methodology mentioned in Chapter 4 are good examples. They are created as controls (type: Policy) and linked to the relevant requirements and risks, exactly like any other control. There’s no need for separate document management outside Kordon.

A control’s state (Implemented / Not Implemented / Failing) is calculated automatically based on the completion of its linked tasks. It cannot be manually set to “Implemented”. The next chapter describes how this works.

6. Making It Operational: Tasks and Evidence

This is where the ISMS turns from paper into real activity. A task is Kordon’s general-purpose tool for recurring or one-off work, and it doesn’t have to be linked to a control. A task can be linked to any object that needs recurring activity: a control, a risk, an asset, a vendor, a business process, or a finding. Running an ISMS therefore isn’t only about working with controls; a large share of day-to-day activity runs through the same tasks, just linked to a different object.

Some examples of which objects tasks are typically created against:

Linked object	Example task
Control	Weekly backup check, quarterly restore test, annual audit
Risk	Periodic reconfirmation of a risk acceptance decision (see Chapter 4)
Asset	Annual inventory or asset review (see Chapter 3)
Vendor	Security assessment at onboarding, annual vendor review, revoking access at offboarding (see Chapter 3)
Business process	Business continuity test
Finding	Remediating a gap or implementing an improvement (see Chapter 9)

Choose the right type for every task:

Type	Behaviour	Use when…
Maintenance	Simple done/not done	Recurring operational work, e.g. backups, patching, asset inventory
Review	Requires an OK / Not OK decision	A periodic assessment, e.g. reviewing a rule or policy, a vendor review, or reconfirming risk acceptance
Audit	Requires an OK / Not OK decision; “Not OK” immediately moves the control to Failing	A formal internal audit of a specific control. This type is used only for control-linked tasks, since only a control has a Failing state

Set a frequency: once, weekly, monthly, quarterly, semi-annually, annually. A recurring task’s next due date is calculated from the original due date, not the completion date, so the schedule doesn’t drift if a task is completed late.
Assign an owner: a specific person or a user group (when responsibility is shared).
Where relevant, require evidence for task completion: a text note, a screenshot, a log file.

7. Statement of Applicability (SoA)

Review the applicability decisions now that risks and controls are documented. Confirm or refine each requirement’s justification, drawing on its linked risks and controls.
The SoA is directly visible and readable within Kordon in the requirements view: each requirement’s applicability, justification, and linked controls sit together in one place, typically easier to follow than a separate document. If needed, the same information can also be exported as CSV, for example to share with someone who doesn’t have access to Kordon, but this isn’t a required step for managing the SoA.
Consider giving the auditor read-only access directly to Kordon at this stage already. This avoids a lot of back-and-forth email later when sharing evidence.

8. Performance Evaluation and Internal Audit (ISO Clause 9: performance evaluation)

Monitor the Health indicators regularly on business processes, assets, and vendors. An “At Risk” state immediately points to where there’s an unacceptable risk, an overdue task, a failing control, or an open finding.
Track compliance coverage: a requirement is considered covered once at least one linked control is in the “Implemented” state. This is a dynamic indicator: if a control moves to “Failing”, the requirement loses its coverage immediately, not just at the next review.
Run formal internal audits through Audit-type tasks. When the auditor opens the task, they see every related task completed during that period along with its evidence, all in a single view. This makes running an internal audit in Kordon significantly faster than gathering evidence from separate systems.

9. Findings and Corrective Actions

Document a finding as soon as it’s discovered: during an internal audit, a vendor review, an incident, or as a general observation.
Choose the right subtype:
- Incident: a security event that actually occurred
- Opportunity for Improvement (OFI): an identified weakness that hasn’t caused harm yet
- Nonconformity (NCR): a control, process, or activity that doesn’t meet a stated requirement (a common internal audit outcome)
Set a priority and track status through to closure.
Link the finding to the relevant objects: the requirement (that it speaks against), the control (that failed, or that’s being created to resolve it), the risk (that materialised), the asset or vendor (that it concerns).
Create a remediation task to resolve the finding and complete it with evidence. This closes the feedback loop and keeps the finding visible in Kordon until it’s resolved, instead of it becoming a forgotten note.

10. Management Review

Kordon provides the input needed for a management review directly, without having to compile a separate report:

Health of business processes, assets, and vendors
Failing controls and their impact on linked risks
Open findings (Incident/NCR/OFI)
Residual risk scores (mitigated vs unmitigated)
Fulfilment of applicable requirements

Document the review’s decisions and conclusions in Kordon, for example as a finding (if a gap requiring remediation was identified) or as a task (if the decision implies a specific next step).

11. Continual Improvement

An ISMS doesn’t end with the certification audit. Chapters 4 through 10 form a cycle that repeats:

New risks emerge → linked to existing or new controls
Controls need adjusting → tasks are updated accordingly
Findings generate remediation tasks → the fixes may in turn change risk or control ratings
Requirement applicability is reviewed every time the business context changes

Kordon’s recurring task mechanism (Chapter 6) ensures this cycle runs on a calendar, not just in the run-up to an audit.

12. Readiness for the Certification Audit

A practical checklist before the certification audit:

All ISO 27001 requirements have been reviewed, with applicability set and justified
The SoA is up to date in Kordon and available to the auditor if needed
Every “applicable” requirement is covered by at least one “Implemented” control
There are no overdue tasks or “Failing” controls
At least one full internal audit cycle has been completed (Audit-type tasks completed)
A management review has taken place and been documented
Open findings are either resolved or deliberately deferred with a documented justification
The auditor has been given read-only access to Kordon

13. API, AI, and Automation

Everything described above can be done through the Kordon user interface, but the platform also offers a full REST API that covers the same functionality. This is useful for bulk imports, integrations with existing systems, or automating recurring maintenance tasks.

Base URL: https://<domain>/api/v1/
Authentication: Authorization: Bearer <token>. You can use either a user-linked key (actions are logged under that user’s name) or a bot key (actions aren’t tied to a specific person, suited to integrations).
Resources: risks, controls, assets, vendors, findings, regulations, requirements, tasks, settings/users, settings/user-groups, custom_fields, labels
Connections (e.g. control ↔ risk, controls ↔ risks in the API) are managed via PATCH /:resource/:id/connections. Each request sends the full set of desired connections; it’s a replacement, not an addition.

Full API documentation: https://kordon.app/learn/api/

AI Agents and Kordon-specific Skills

Because Kordon’s entire data model is built on consistently connected objects (requirements, controls, risks, assets, vendors, business processes, findings, tasks), it’s well suited to working with AI agents too. Within the Kordon ecosystem there are Kordon-specific skills, meaning instructions written for AI agents about the platform and its API, that let an agent:

Enter data quickly and in bulk via the API, for example a bulk import of assets, vendors, or risks when setting up a new client account.
Analyse existing ISMS content, drawing on the fact that every object is connected to every other. For example, identify controls with no link to a risk or requirement, or risks that don’t yet have any mitigating control attached.
Enhance and correct existing data, for example writing more specific control descriptions based on linked assets and vendors, or refining requirement applicability justifications.

This makes an AI agent a useful assistant both for the initial ISMS setup and for ongoing maintenance: the agent works directly against the Kordon API while understanding what each object and connection on the platform actually means.

Appendix

Suggested Timeline (sample, 4 months)

Month	Chapters	Focus
1	1–3	Information security policy, ownership, requirement applicability, business context
1-2	4–5	Risk assessment, building controls
3	6–7	Rolling out tasks, finalising the SoA
4	8–12	First internal audit cycle, management review, audit readiness

Kordon documentation: https://kordon.app/learn
API documentation: https://kordon.app/learn/api/