System Management Plan – how to build IT system registers, responsibilities, and annual cycles

A system management plan describes how an IT system is to be operated, developed, controlled, and eventually decommissioned. An IT system register is the consolidated list of a company's systems, their owners, suppliers, information content, and key dependencies. Together, they make it easier to allocate responsibility, prioritize measures, and gain control over the system landscape.

What should a system management plan contain?

A useful management plan bridges business needs with ongoing IT operations. It should be followable without turning into an extensive report that no one uses. The content may differ between a small company with ten SaaS services and a business with proprietary business systems.

Who is a system owner – and what is the difference from a system administrator?

The system owner is typically the role appointed by the business to decide on goals, priorities, and resources for the system. The system administrator usually coordinates the practical work, documentation, and follow-up. IT operations handle technical tasks according to the division of responsibilities applicable within the organization or supplier.

These are organizational roles, not a universal legal classification. A smaller company may combine several tasks under one person, but decisions, practical execution, and control should still be clear. When processing personal data, it is also important to distinguish an internally appointed system owner from the legal role of data controller under GDPR.

Create an IT system register step-by-step

1. Inventory systems actually in use

Include business systems, accounting systems, HR tools, SaaS subscriptions, integration platforms, and systems used by individual teams. Look for duplicates and services that lack a clear requester. Also register systems that are being phased out.

2. Document basic information

Enter the system name, purpose, main process, supplier, system owner, main users, contract owner, cost, contract term, and contact path for incidents. Preferably indicate where associated agreements and technical documentation are stored, without storing passwords or other secrets in the register.

3. Identify information and dependencies

Note which information assets the system handles, key integrations, data flows, and critical business processes. Follow up on confidentiality, integrity, and availability. An inventory becomes particularly valuable when the same data can also be used in risk assessments and continuity planning.

4. Distribute responsibility with a simple RACI matrix

Define who is responsible for decisions, who performs an activity, who is to be consulted, and who is to be informed. Link roles to, for example, change approval, access control, incident management, and renewal of supplier agreements.

5. Prioritize risks and improvements

Assess the consequence and probability of relevant disruptions. Document risk owners, countermeasures, decisions, and follow-up dates. Avoid using a single score as an automatic replacement for the business's assessment.

6. Create an annual cycle

Plan regular checks of user access rights, recoverability, supplier performance, costs, licenses, support tickets, and decided improvements. Adjust the frequency according to each system's significance and risk profile.

7. Review lifecycle and decommissioning

When a system is to be replaced, clear decisions are needed regarding data export, data migration, closing access rights, purging, archiving, and contract termination. Specifically check that personal data and accounting information are handled according to the respective applicable rules.

Example: three systems in a small company

Assume the company uses an accounting system, an HR system, and an external helpdesk. The CFO can be appointed system owner for the accounting system, the HR manager for the HR system, and the IT manager for the helpdesk. The IT function can simultaneously perform common technical controls. For each system, the supplier, contract renewal, information classification, main risk, and next control date are registered.

The example shows why a system register and a management plan fulfill different tasks: the register shows what exists, while the plan describes what needs to be done, by whom, and when.

Is an IT system register the same as the GDPR register of processing activities?

No. An IT system register describes systems and technical or organizational resources. GDPR Article 30 regulations, conversely, concern a register of processing activities and require specific information, including purposes, categories of data subjects, and recipients where requirements are applicable. An IT system may support several personal data processing activities, and one processing activity may include multiple systems. The register of processing activities must therefore be assessed separately.

Read our existing guide on the register of processing activities under GDPR Article 30 for the correct content for that document.

Checklist for system management

• All important IT systems are included in the register.
• System owner, operational manager, and supplier are identified.
• The system's purpose, dependencies, and information assets are described.
• Risks, changes, and decisions are documented.
• Access rights review and incident procedures have designated responsible parties.
• License and contract dates can be monitored.
• Annual cycle and control results are followed up.
• Decommissioning and data export are planned for systems to be replaced.

Common mistakes to avoid

• Systems without owners: No one has the mandate to prioritize improvements.
• Registers without an update routine: Information quickly becomes outdated.
• Mixing up roles: IT support is automatically assumed to carry all business and data protection responsibility.
• Forgotten SaaS services: Costs, integrations, and external storage locations are overlooked.
• No exit plan: It is unclear how data will be moved or deleted when agreements end.

Common questions about the system management plan

Must all companies have a system management plan?

There is no general Swedish legal requirement that every company must have a specific document named a "system management plan." Specific businesses may be subject to other binding requirements regarding governance, security, documentation, and control. The plan is therefore a practical management tool that can help the organization meet relevant obligations.

What is the difference between an IT system register and a license register?

The system register describes the system's purpose, owner, information handling, and lifecycle. The license register focuses on subscriptions, number of licenses, costs, and renewal dates. The registers can be linked together.

How often should the system management plan be updated?

Determine a recurring review based on risk and the pace of change. Also update after major system replacements, incidents, organizational changes, and significant supplier changes.

Can the same person be both system owner and system administrator?

Yes, in smaller organizations, roles can be combined. Even so, clearly document who makes decisions, performs controls, and is responsible for ensuring deficiencies are addressed.

Related guides and templates

Deepen your work through our guides on information classification, access rights review, incident management plan, and SaaS exit and data migration. Also see templates for IT agreements and digital services.

Sources and further reading

• IMY: Keep a register of personal data processing activities
• IMY: Corporate handling of personal data
• Informationssakerhet.se: Method support for systematic information security work

Last fact-checked: October 13, 2026. The article provides general business guidance and is not legal advice. Verify whether your business is subject to specific sectoral requirements, agreements, or regulations.