E-ITS implementation often feels abstract at first. In practice, it starts with a very concrete question: what does the organization actually do, and what does that depend on?

That is why defining business processes matters so much for information security. Before you can protect anything, you need to understand which activities create value in the organization, who is responsible for them, and which systems and data they rely on.

What is a business process in the E-ITS context?

Simply put, a business process is a repeatable sequence of activities that helps fulfill the organization’s purpose or deliver a service.

There is an important distinction to make here:

  • A service describes what the organization delivers to an external customer or citizen
  • A process describes how that service is delivered internally

For example, a local government’s service might be “social welfare provision,” but the process happening inside that service is “processing social benefit applications.”

From an information security perspective, the focus must be on processes — because that is where you will later map assets, dependencies, and protection needs.

Why are business processes the backbone of E-ITS?

Business processes connect:

  • organizational goals
  • services provided
  • information systems and data in use
  • risks and controls

Without this connection, information security becomes too technical and detached from what the organization is actually trying to protect.

1. Start from the organization’s goals

It makes sense to begin mapping from a higher level. Look at what the organization’s core tasks are and why it exists.

Useful sources include:

  • founding statutes
  • statutory tasks
  • strategic objectives

A good starting question is simple: what do we do and why does it matter?

For a local government, statutory tasks already point the way — social welfare, spatial planning, municipal utilities, waste management, and so on.

2. Create a list of business processes

Once the core goals are clear, break them down into specific processes.

A practical rule of thumb: one service typically has 1–5 main processes behind it. This helps avoid two common extremes:

  • descriptions that stay too general
  • descriptions that get too granular

Examples:

  • Service: social welfare and services

    • Process: processing social benefit applications
    • Process: handling child protection cases
    • Process: organizing home care services for the elderly
  • Service: spatial planning

    • Process: processing building and occupancy permits
    • Process: initiating and establishing detailed plans

When you are unsure whether something is a service or a process, ask:

  • does this describe what we provide or how we do it?
  • does it describe external value or an internal chain of activities?

Once the processes are written down, connect them to their actual dependencies.

For each process, think through at a minimum:

  • which information systems it uses
  • which data or registers it processes
  • which technical assets it depends on

For example, the process “processing social benefit applications” might depend on:

  • STAR (the national social register system)
  • a document management system
  • population register queries
  • social workers’ computers
  • a working network connection

This kind of map makes information security genuinely manageable, because it makes visible which business activities would break down if a specific asset or system went offline.

The business-side owner must be clear

Under E-ITS logic, a process cannot simply be left for IT to manage. Every process must have a business-side owner who understands its purpose, impact, and value.

This matters because:

  • IT alone cannot decide on a process’s business importance
  • protection needs must reflect the real operational impact
  • risks must be tied to organizational activities, not just technical infrastructure

In addition to the business-side owner, it is useful to assign a technical custodian who knows the systems and assets supporting the process.

Common mistakes

The same mistakes tend to repeat in business process mapping:

  1. treating a service and a process as the same thing
  2. not assigning a business owner to the process
  3. processes staying either too broad or getting broken into pieces too small
  4. producing the map as a one-time project and never updating it again

The last point is especially important. A business process description is not a one-off document — it is a living part of the management system. New tools, new services, and changing responsibilities all need to flow into it continuously.

What information to document for each process?

A useful minimum per process:

  • name
  • type (e.g., core process or support process)
  • purpose
  • brief description
  • business-side owner
  • technical custodian
  • reference documents or legal basis
  • data processed
  • related information systems and assets
  • external partners or other stakeholders

Once this information is in place, the next steps become much easier — you already have the foundation for linking assets, vendors, and risks.

How Kordon helps

You can start in Excel and separate documents, but managing the connections between processes, assets, risks, and owners in one place gets complicated quickly.

Kordon helps build a shared model where each process can be linked to:

  • its owner and technical custodian
  • reference documents
  • assets and information systems
  • partners
  • related risks and controls

The advantage is straightforward: information doesn’t have to live in separate tables. When a system changes or an incident occurs, you can immediately see which processes are affected.

Summary

Defining business processes is one of the most important steps in E-ITS implementation because it gives information security real business context.

A good starting point is to:

  • begin with the organization’s goals
  • break services down into internal processes
  • link processes to systems, data, and assets
  • assign a clear owner to each process
  • keep the documentation up to date

When this foundation is in place, the asset register, risk analysis, and control selection all become much clearer.