In recent years, digital sovereignty has become a central concept in discussions about technology, geopolitics and digital infrastructure. In its publication on the topic, the Danish IT Industry Association describes digital sovereignty as the access and ability to develop, use, protect and maintain critical technologies necessary for economic, security and political independence.

Behind this definition lies the recognition that modern societies are deeply dependent on digital infrastructures and global technology providers. When data, systems and digital services operate within infrastructures that organisations or states do not themselves control, a strategic dependency arises.

Managing technological dependencies is not in itself a new challenge. Organisations have always had to deal with risks such as system failures, supplier dependencies or technological obsolescence. What has changed is the degree of dependency, which today gives the issue a different character.

A large share of organisations’ digital environments is now based on service-based platforms delivered by a small number of global providers. These platforms are often deeply integrated into daily operations and work processes, making them difficult both to replace and to move. Technological dependency therefore becomes both more pronounced and more extensive. It is no longer sufficient to view such dependencies as local IT risks. Instead, they increasingly represent strategic risks. Their management consequently moves into executive management and boardrooms under the heading of digital sovereignty.

The question, then, is what this means in relation to organisations’ documents and information assets.

Digital Sovereignty in Document and Information Management

In this article we explore what digital sovereignty may mean in the context of document and information management. The concept is still relatively new in this context, but it is reasonable to ask whether well-established professional disciplines already contain many of the tools needed to address it.

As described above, the concept of digital sovereignty arises from the recognition of technological dependencies. When organisations depend on technologies and infrastructures they do not control themselves, the question arises of how much influence they actually have over the frameworks within which their digital activities take place.

Ultimately, digital sovereignty therefore becomes a question of control. The central issue is not necessarily whether an organisation can eliminate its technological dependencies, but rather to what extent it can retain control – and freedom of action – over the technologies and infrastructures on which its digital activities depend.

For professionals working with document and information management, the idea of control immediately sounds familiar. In this field, control over information has always been a central concern.

A closer look quickly points to several fundamental elements of what control over organisational documents actually consists of.

The first is overvew.

Overview of Information Assets

In practice, organisations store documents in many different places. They may be located in collaboration platforms, case management systems, quality management systems and other specialised applications. They may also be stored in shared drives or in document libraries connected to projects and work processes. In addition, older systems and archives often hold historical documentation.

Having control over documents therefore begins with the ability to form a coherent overview of this information landscape. The organisation must know where its documents are located and which systems and technologies they depend on.

In practice, such an overview also requires the organisation to define the types of documents it actually holds. Without an understanding of what the information consists of, it becomes difficult both to map and manage it.

Which Documents Are Important?

However, an overview of documents is not sufficient in itself. Organisations produce large quantities of documents, but not all of them have the same significance.

Some documents serve primarily a temporary role in work processes – for example drafts or working notes. Other documents have far greater importance for the organisation. These may include contracts, regulatory documentation, quality system documentation, project decisions or technical documentation related to products and intellectual property.

When documents serve such functions, they act as documentation of the organisation’s activities and decisions. It is therefore essential that they remain usable in that capacity. Control over information assets therefore also involves knowing which documents have this status.

The Context of Documentation

In information science, such documents are referred to as records, and their continued value as documentation depends on proper handling.

Records management standards, including ISO 15489, describe this through concepts such as authenticity, integrity, reliability and usability.

The credibility of documentation depends to a large extent on the context in which it exists and the processes it has undergone. This context may include information about who created the document, when it was approved, what role it played in a process, or which versions existed along the way. Classification, metadata and version history can therefore be crucial to how a document is understood and used as evidence.

Documentation must be preserved in a way that makes it possible to understand what the document is, where it originated, and what role it played in the organisation’s activities.

When dealing with records, control therefore concerns not only the document files themselves but also the context that makes the documentation meaningful.

Technological Embedding

In practice, this context is often closely embedded in the systems where documents are managed.

Metadata capturing the document’s context is often stored within the system. Version histories are maintained within system functionality. Classification structures and access rights are governed by system logic and data models. A large portion of the information that gives documentation its meaning therefore does not exist independently of the technological environments where documents are processed.

This also means that the value of documentation becomes dependent on these technologies. If a system changes, is phased out or replaced, the organisation’s ability to preserve the structure and coherence of its documentation may be affected.

When analysing what it means to have control over information assets, this adds a technological dimension. Organisations must understand and manage the metadata and processing traces that are essential for their records to retain their documentary value.

What Does Control Over Documents Mean?

Bringing these perspectives together suggests that control over documents in a digital sovereignty context consists of several elements.

Organisations must have an overview of their information assets and know where documents are located. They must be able to distinguish between documents that merely support work processes and those that function as documentation of organisational activities. They must understand the context and metadata that make documentation trustworthy. And they must understand the technological environments on which this documentation depends.

Seen in this light, digital sovereignty in document and information management is not primarily a technological question. It is a question of an organisation’s ability to maintain control over its information assets and their documentary value – even when they are embedded in digital systems and platforms.

At the same time, the analysis points to something else: much of what is described here as responses to digital sovereignty challenges already exists within established professional disciplines. Information specialists, records managers and others who work professionally with information management already deal with overview of information assets, assessment of document significance, understanding of documentary context and management of technological dependencies.

Digital sovereignty in document and information management is therefore not necessarily a new discipline that must be invented from scratch. Rather, it represents a new perspective on a familiar professional domain, where classical disciplines within information management acquire a clear strategic significance.

When an organisation replaces a system, consolidates platforms, or shuts down an older solution, a question about the documents almost always arises: How do we get them into the new system?

If you have not previously worked with document migration, the task may sound relatively straightforward. The files simply need to be moved from one system to another. But that understanding only holds as long as documents are regarded as ordinary files. In practice, documents in organisations are almost always more than that.

For many documents – and especially for those we consider records – the value does not lie solely in the content of the file. The value also lies in the documented context: who created the document, when it was approved, which case or process it belongs to, and which version is the valid one. When such documents are moved from one system to another, the task is therefore not simply about moving files. It is about preserving evidence.

Documents Are Not Just Files

A document in a document management system typically consists of several elements. There is the content file itself – for example a Word document or a PDF. But there is also metadata describing the document, as well as relationships to other documents or objects in the system.

Metadata can be relatively simple information such as title or document type. But in many cases metadata also contains information that is crucial for the meaning and credibility of the document. This may include approval information, version history, or its relation to a particular case, product or process.

Documents are also often part of structures and contexts. A document may be one version within a version chain, part of a case file, an attachment to another document, or part of a larger documentation set. These relationships help define the document’s context.

When documents are moved from one system to another, this context must follow them. Otherwise the documents may exist in the new system but without the connections that make them understandable and trustworthy.

Records Require Preserved Context

The difference between data and records becomes particularly clear in this context.

Structured data can often be moved relatively mechanically from one database to another. Fields can be mapped to new fields, and values can be transformed according to relatively clear rules.

Documents and records behave differently. Here, metadata is not merely a technical attribute but part of the document’s evidential value. If, after migration, it is no longer possible to see who approved a document, when it was approved, or which version was valid at a given point in time, the value of the document as evidence is significantly reduced.

In some organisations this may primarily be a matter of internal trust in the documentation. In others – particularly in regulated environments – it can have more formal consequences. Here documentation may form part of the evidence underlying regulatory approvals, quality management systems or traceability requirements.

This does not mean that all documents require the same level of control during migration. But when documents function as records, the migration must be designed with the objective of preserving their integrity and context.

When Documents Leave Their System

A significant challenge in migration arises at the moment documents leave the system in which they were originally created and managed.

In the original system, the structure, metadata and relationships of documents are typically managed by the system’s own logic. The system knows how versions relate to each other, how documents connect to cases or processes, and which metadata fields are mandatory. Not least, the content file itself is protected.

When documents are exported, this system logic temporarily ceases to protect them. The documents exist for a period outside their original context. It is during this phase that the risk arises that metadata may be lost, relationships broken, values altered unintentionally – and the content file may become corrupted either through technical error or through malicious interference.

The migration task therefore consists of establishing a controlled process in which the documents – meaning both the content file and the metadata, as well as the relationship between them – remain under full control during their transition from the source system to the receiving system.

This may involve transforming metadata if the new system organises information differently from the old one. But such transformations must be consistent, documented and controlled so that it is possible afterwards to explain and demonstrate how the documents were handled during the migration.

Relationships Must Be Re-Established

Another challenge arises from the relationships between documents.

Documents rarely exist in isolation. There may be multiple versions of the same document, different renditions (for example in different file formats), or relationships to other documents within a case or process.

If such relationships are not handled correctly during migration, the result may be that documents lose their connections to each other. Version trees may be broken, attachments may become detached from their parent documents, and documents may end up without the context that explains their role.

A migration therefore often requires a carefully planned sequence for loading documents into the new system. Original versions must be created before subsequent versions, and related objects must exist in the system before relationships between them can be established.

It is precisely considerations like these that make document migration a discipline in its own right and distinguish it from the migration of structured data.

The Real Purpose of Migration

Viewed from the outside, migration can appear to be a technical exercise: export from one system, import into another.

But if the documents have value as documentation – as records – the purpose is different. The purpose is to ensure that after migration the documents can still be used as trustworthy evidence of what they represent.

This means that it is not enough simply to be able to find the document in the new system. One must also be able to understand its context and trust that it is the same document that previously formed part of the organisation’s processes.

Migration therefore becomes not merely the movement of files, but a controlled transfer of documentation.

Conclusion

In some situations it may be entirely sufficient to copy files from one system to another. If the documents have no particular documentary significance and their metadata does not play an important role, a simple file transfer may be a practical solution.

But when documents function as records, the task changes in nature. It is no longer enough to move the content file alone. Metadata, relationships and the context that make the document trustworthy documentation must also be preserved.

This is why we speak of document migration, not simply file transfer. The real task of migration is not to move documents from one system to another, but to ensure that the evidence contained within them survives the system change.

When Compliance Is Reduced to Documentation

When organisations establish a compliance or governance framework, the work almost always begins with documentation. Policies must be formulated, procedures described, and responsibilities and workflows clarified. This is a necessary and important part of creating a shared foundation for governance.

Once policies have been written, procedures published, documents placed in a system, and relevant employees informed and trained, the implementation phase is largely complete. The organisation has articulated its rules and made them accessible.

But documentation is only the starting point. Regulatory requirements ultimately do not focus on the documents themselves, but on the organisation’s actual actions – and on the ability to demonstrate that these actions have been carried out in a controlled manner.

There is therefore an important distinction between documentation and documented behaviour. Documents can describe how something should be done. Compliance only emerges when the organisation’s actions follow the established guidelines and when those actions leave traceable evidence.

Documents establish the framework. Evidence only arises through the actions and records that demonstrate that the guidelines have actually been followed in practice.

When Governance Shifts from Documents to Actions

Once the foundational documentation has been established, the real work begins. The focus shifts from describing the rules to ensuring that they are followed in practice.

At this stage, it becomes clear that compliance is not primarily demonstrated through policies and procedures, but through the traces left behind by the organisation’s actions. These may include records of approvals, changes in systems, access assignments, or the handling of incidents.

A change control procedure does not in itself create control over changes. A policy on access management does not in itself ensure correct access. And an incident management procedure does not in itself handle a security incident.

Documents describe the expected behaviour. Compliance can only be demonstrated when the organisation’s systems and processes support that behaviour in practice – and when they simultaneously record what was done, by whom and when.

It is within this recorded behaviour that the true evidence of compliance emerges.

Documents Describe – Systems Document

If compliance is not primarily about documents, what is it about? It is about documented control.

In this context, control means that the organisation performs specific actions under defined conditions as part of its processes. The term is used here in the professional sense of a control mechanism – not in the everyday sense of checking something (or someone). Documented control means that these actions can be demonstrated afterwards.

Documents still play an important role in this context, but in a different way than often assumed. They describe the controls and define the framework for the work. The evidence itself arises from the records of the actions that are carried out.

When a manager approves a document in a system, the evidence is therefore not the document itself. The evidence is the record of the approval: who approved it, when it was approved, and which version was approved. Similarly, in change management it is not the procedure that documents compliance, but the history of assessments, decisions and implemented changes.

Documents establish the framework for behaviour. Evidence arises in the traceable records showing that controls have actually been performed.

Controls in Practice

When looking at organisational control environments, this principle becomes visible in a number of familiar mechanisms.

Approvals are an obvious example. When a contract, report or change is approved, the system typically records who approved it, the time of approval and which version was approved. These records constitute traceable evidence.

The same applies to change control. When changes are registered, assessed and implemented through a controlled process, a history of decisions and actions emerges that makes it possible to demonstrate afterwards how the change was handled.

Access management and incident management function in much the same way. Compliance is not documented through the access policy or the incident management procedure, but through the records showing who received access, which incidents occurred, and how they were handled.

The common characteristic is that evidence arises through the recording of actions.

The Role of Systems

When compliance is understood as documented behaviour, the role of systems becomes central.

Digital systems make it possible to record actions consistently and uniformly. They can ensure that approvals are recorded with identity and timestamp, that changes are not implemented without a documented decision, and that history is preserved through audit trails.

In this way, systems become the framework within which the organisation’s controls are both performed and documented. It is this traceability that makes it possible to review afterwards what has taken place.

Compliance therefore does not arise in the document repository alone, but in the interaction between documents, systems and the actions performed by the organisation’s employees.

From Document Management to Documented Control

Document management is an important discipline because it ensures that the organisation’s policies, procedures and instructions are clear, accessible and version controlled.

But compliance is ultimately not assessed based on the structure of documents. It is assessed based on whether the organisation’s controls are actually performed – and whether they can be demonstrated.

It is therefore documented behaviour that forms the core of a well-functioning control environment. Documents describe how the work should be carried out. Systems and processes create the evidence that it actually happens.

Most people have an intuitive understanding of what a document is. We often imagine a file – typically a Word document or a PDF. In everyday work situations, this understanding works well enough. But when documents become part of regulatory contexts, quality systems, or controlled processes, greater precision becomes necessary.

This is mainly because of one question: When is a document simply a document – and when is it a record?

The distinction is not merely linguistic. It has direct implications for an organisation’s compliance responsibilities and for how documents must be handled, stored and controlled.

This article explores the difference and explains why it is a central issue in professional document and information management.

A Document Is More Than a File

When working formally with documents, they cannot be reduced to a file stored on a drive or in a system. A document consists of two key components.

The first is the content – often referred to simply as content. This may be a text file, but it can also include images, audio, video, or several files that together constitute the document’s content.

The second component is metadata. Metadata describes the document and the context in which it exists. This may include information about the author, the creation date, version history, its relation to a process or a case, as well as many other types of information. Metadata is often used to locate documents again, but its role is far more fundamental than search alone.

Metadata helps establish the document’s context. When we look at an email, for example, information about the sender, recipient and time of transmission is essential for understanding the content. Without this information, the document loses an important part of its meaning.

In professional terms, a document therefore consists of both the content file(s) and the metadata. Only when these elements are considered together do we have the complete document.

This distinction may appear technical, but it becomes crucial when documents must be handled correctly throughout their lifecycle.

From Document to Record

The concept of a record introduces another layer of understanding.

A record is commonly defined as documentation or evidence of a business transaction.

This means that a document becomes a record when it is used to demonstrate that something has occurred. This could be an approval, a decision, a delivery, a test, a change, or communication that has significance for the organisation’s activities.

In practice, this means that many documents eventually acquire the character of records. Not because they were originally created for that purpose, but because they come to document something significant.

An approved procedure document provides a clear example. During its drafting phase, the document is a working document. But once the procedure is approved and enters into force, it serves as documentation of how the organisation has formally established a particular practice.

Similarly, an email, a test result, a report or many other forms of information may become a record if they demonstrate that an activity has been performed or that a decision has been made.

Records are therefore not a special type of file, but a document that gains the status of a record through its function.

Records Require Controlled Handling

When a document functions as evidence, a new requirement arises: it must be handled in a way that makes it trustworthy.

Within records management, this is described through four key characteristics: authenticity, reliability, integrity and usability. These concepts define when a record can be considered trustworthy documentation.

Authenticity means that the document can be attributed to the correct author and the correct time. It must be possible to demonstrate who created the document and when it was created.

Reliability means that the content of the document can be considered an accurate representation of the activity or decision it describes.

Integrity means that the document has been preserved in a complete and unchanged form, so that it has not been manipulated or altered without control.

Usability means that the document can still be found, opened and understood within its context.

These principles are described in international records management standards, including ISO 15489.

In practice, this means that if an organisation wants to be able to demonstrate to a third party (ultimately perhaps in a court of law) that a document is genuine and has not been manipulated, the handling of the record throughout its lifecycle must ensure that it satisfies these four principles: authenticity, reliability, integrity and usability.

This is where the compliance dimension emerges.

When a document functions as a record, it becomes necessary to demonstrate – and ideally document – that the document has been handled correctly throughout its lifecycle.

Typically this means that documents are created and registered in a controlled way so that their origin and context are known. They are subsequently handled under version control so that it is clear which changes have been made and when. Once a document has been approved and functions as a record, the possibilities for further modification are restricted, and the document is stored in an environment where it is protected against loss or manipulation. Finally, the organisation must be able to demonstrate how the document is either archived or disposed of in accordance with established rules.

In regulated environments these requirements are often formalised through procedures and system requirements, but the underlying principles apply more broadly.

Metadata as the Carrier of a Document’s Trustworthiness

Metadata plays a particular role in this context.

When a document is created within an IT system, the system often automatically generates metadata such as the creation time and the author. These details can later help demonstrate when the document was created and who was responsible for it.

If such metadata disappears or is altered without control, it can become difficult to demonstrate the document’s authenticity. The document then loses part of its evidential value.

It is therefore essential to identify which metadata is significant for the document’s integrity. This metadata must be managed and preserved with the same care as the content file itself.

This becomes especially evident in situations such as system migrations or archiving processes. If the focus is only on moving files while failing to preserve the metadata that provides context, organisations risk being left with information that can no longer function as documentation.

In some situations this may simply be impractical. In others it can have serious regulatory consequences.

Not All Documents Are Records

It is important to emphasise that not every document within an organisation is a record.

There are many working documents, drafts and internal notes that are used solely in preparation or internal coordination. These documents do not in themselves constitute documentation of a business transaction and therefore do not need to be handled as records.

However, a document may become a record the moment it is used to document an activity, decision or delivery. The boundary that shifts is therefore not between different document types, but in the document’s function within the organisation’s documentation of its activities.

A document may begin its life as a working document and later become part of the documentation of a decision or process. When that happens, the document’s role changes and it must be handled in accordance with the principles that apply to records.

This primarily requires that the organisation has a clear understanding of which documents form part of the documentation of its activities.

Why a Document Becoming a Record Changes Your Compliance Responsibility

When a document functions as a record, the organisation’s responsibility fundamentally changes.

The document is no longer simply information. It is documentation. It must be capable of demonstrating what the organisation has done, decided or delivered.

Handling the document therefore becomes part of the organisation’s documented control. If the document cannot be produced, if it does not appear authentic, or if it can no longer be understood within its original context, the value of the documentation is weakened. In some cases this may mean that the organisation cannot demonstrate compliance with internal procedures or external requirements.

This is why the question of when a document becomes a record is not merely theoretical. It is a practical question of information responsibility.