What may at first glance look like a highly IT-technical task, on closer inspection requires both significant business knowledge and support from the traditional disciplines involved in the sound management of information, documents and data – hereafter, for simplicity, simply referred to as “data”. It is this information-management perspective on NIS 2 that we will examine more closely in a couple of articles. In this first article, we look at the requirements and issues that the rules directly and indirectly give rise to in the management of data, and how we can identify the data on which the company is particularly dependent – the data we will refer to as “critical data” in this article.

Introduction: What is NIS 2 fundamentally about?

And why can you, as someone who works with the company’s data, documents and information, contribute?

NIS stands for Network and Information Systems. NIS 2 is the EU’s second directive on cybersecurity in network and information systems.

The fundamental purpose of NIS 2 is to ensure that companies and organisations on which society depends are sufficiently resilient to cyberattacks, system failures and other digital incidents. It covers a number of sectors, including energy, transport, healthcare, financial market infrastructure and digital infrastructure.

NIS 2 sets requirements, among other things, for how the companies and organisations covered by the directive must manage cybersecurity risks, prevent and handle incidents, ensure business continuity and report significant incidents. The requirements cover technical, operational and organisational measures.

What do the rules say – directly and indirectly – about data?

The NIS 2 Act defines a network and information system. The definition consists of three parts:

a) an electronic communications network,

b) devices that, by means of software, process digital data, and

c) the digital data stored, processed, retrieved or transmitted by these elements.

The wording of the law in point c is:

“Digital data stored, processed, retrieved or transmitted by elements in points a and b for the purpose of their operation, use, protection and maintenance.”
(Source: NIS 2 Act, Section 3, no. 21, point c – NIS 2 Act = Act no. 434 of 6 May 2025).

With regard to network and information systems, the NIS 2 Act states that the companies and organisations covered by the legislation must implement appropriate and proportionate technical, operational and organisational measures to manage the risks to their security. This includes, among other things, incident handling, business continuity, backup and recovery, supplier security, access control and asset management.

And what does security mean when we look specifically at the data? Here, the law is very direct. In the definition of security in network and information systems, it states that the systems must be able to withstand events that may be:

“[…] detrimental to the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data […]”
(Source: NIS 2 Act, Section 3, no. 28).

This means that the protection of data is not merely something we infer from the rules. The availability, authenticity, integrity and confidentiality of data are explicitly part of the concept of security on which NIS 2 is based.

So there is a clear task within the field of information management: to contribute to identifying and protecting the data involved in the operation, use, protection and maintenance of the systems.

But there is also a less direct – and equally important – information-management task.

NIS 2 includes requirements for, among other things, incident handling, business continuity, backup and recovery, crisis management, supplier security, access control and asset management. To perform these tasks in practice, the company depends on information whose importance does not necessarily stem from the fact that it is directly processed in the systems supporting operations, but from the fact that it is necessary to operate, protect, handle incidents involving, or recover the systems and the services they support.

This could, for example, be operational and contingency procedures, plans for emergency operations and recovery, information about system and supplier dependencies, contact and escalation lists, overviews of critical assets, recovery priorities, configuration information or documentation that tells employees what to do when normal operations are no longer functioning.

It is therefore not sufficient simply to look inside the systems and ask what data they contain. We also need to look around the systems: at the workflows, people, suppliers and information needed to keep operations running or restore them after an incident.

Some of this information may only prove to be truly critical when the normal situation breaks down. A contingency procedure that is almost never used in day-to-day operations may, for example, be essential during an incident. The same may apply to an up-to-date contact list or documentation describing how a critical service is operated manually until the normal systems are available again.

NIS 2 does not explicitly state that the company must create a specific category called critical data. But when the requirements are translated into practice, there is a fundamental question that is difficult to avoid:

What data and information does the company depend on to maintain its critical processes and services – both during normal operations and when something goes wrong?

These are what we refer to as critical data in the following.

What information-management questions does NIS 2 raise?

When we translate the requirements into the practical management of data, a number of questions become relevant. This is not a legal checklist, but an information-management way of breaking down the issue:

Criticality: Which data do the company’s critical processes and services depend on – both during normal operations and during an incident?

Dependencies and availability: Where is the critical data located, which systems and suppliers do we depend on to access it, and can the right people access it when needed?

Confidentiality, integrity and authenticity: Is the data protected against unauthorised access and changes, and can we trust that it is complete, genuine and comes from the source we believe it does?

Recovery: If data or systems become unavailable, can the information be recovered in a way that means it can still be understood and used?

Responsibility, control and documentation: Is it clear who is responsible, which requirements apply to the management of the data, and can the company document that the necessary controls actually work?

In this first article, we begin with the first question: Which data is critical – and how do we find it?

How do we find the critical data?

The starting point is the company’s operations. Before we can identify the critical data, we need to know which processes and services the company depends on being able to maintain.

Here, we can use the landscapes and analyses that the company hopefully already works with as a starting point. For example, there may be a process landscape describing the key business processes and a system landscape showing which IT systems support them.

The key point for our further work is that the critical processes and services have been identified.

And here we need to remember the point from earlier: It is not only about the processes supported by the critical systems. It is also about the workflows around the systems that are necessary to keep operations running, protect them or maintain emergency operations if the normal systems are not functioning.

Once the critical processes have been identified – with the business as a central participant – we can begin to look at them through an information-management lens.

For each process, we can ask: Which data, documents and other information must be available for the process to function? And correspondingly: Which information must be available if the process has to switch to emergency operations?

This can be identified through workflow analyses. We follow the individual process and look at what information comes in, what information is used along the way, what is produced, and which information employees depend on to carry out their work.

The result is a picture of the information and data groups on which the company’s critical processes and services depend. These are the company’s critical data.

Where is the critical data located?

Once we have identified the information and data groups on which the critical processes depend, the next question is: Where are they located?

Here, the company’s IT or system landscape is an obvious starting point. It typically shows which systems the company uses, how they are connected, and which business areas or processes they support.

From an information-management perspective, however, a layer is often missing. A system landscape can tell us that the company uses, for example, SharePoint, an ERP system, a maintenance system and a number of specialised systems. It does not necessarily tell us which information groups are actually located in each system.

We can therefore review the system landscape system by system and describe which types of information are stored in them. Under SharePoint, for example, it should not simply say SharePoint, but also include information groups such as operational documentation, contingency plans, customer agreements or technical instructions. The same is done for the other systems and information environments.

Once this has been done, we have an information landscape: a consolidated overview of the company’s information groups and where they are located.

Only then can we connect it back to the workflow analysis.

Here, we have already identified which data the critical processes and services depend on. We can now use the information landscape to determine where this critical data actually resides.

Now we know what needs to be protected

In this way, we identify both the data the company depends on and its location in the landscape where it needs to be protected, accessed and potentially recovered.

The mapping can also reveal dependencies that are otherwise easy to overlook. Critical data may, for example, be distributed across several systems, held by an external supplier or depend on specific integrations in order to be usable at all.

We have therefore, in principle, answered what is critical in the NIS 2 context we are examining here.

But there is an important distinction. A company may have other information that is business-critical for other reasons – for example, because its loss could have serious legal or financial consequences in the longer term. This information will not necessarily be identified through the analysis we are conducting here. Our focus is on the data the company depends on to operate, protect and recover the processes, systems and services that are relevant in the context of NIS 2.

With that distinction, we have created a foundation for moving from identifying the critical data to deciding how it should be managed and protected. In the next article, we look at how we can describe the critical data more precisely and use classification to translate our knowledge of it into concrete requirements for its management.

 

Do all documents need to be transferred to a new system? Not necessarily. This article explains why migrating documentation requires far more work than archiving, when it makes sense to migrate documents or to archive them, and how a professionally informed approach to categorisation can improve quality, save resources and create more breathing space in the run-up to go-live. 

We can refer to a case we encountered at Strator; as part of the replacement of a document management system, we had to handle several million documents in a highly regulated environment. Around 10 per cent of the documentation was to be transferred for active use in the new system. The remainder was to be preserved but not used in day-to-day work, and was therefore placed in an archive. 

The distribution of the workload was striking. Migrating the approximately 10 per cent required around 90 per cent of the workload. Archiving the remaining 90 per cent – approximately three million documents – required the remaining 10 per cent, even though the documents had to be tagged with selected metadata and retention periods and organised into virtual archive boxes as part of the archiving process. 

This did not mean that archiving was taken lightly. The difference stemmed from the fact that documentation intended for active use in a new system must be adapted to a new context. The documents must fit into the system’s structure, metadata must be mapped and, where necessary, enriched, and the result must be checked. Information that is to be retained but is no longer part of day-to-day use can be handled far more simply, as it does not need to be adapted to all the structures and workflows that apply to active documentation. 

This example highlights a key decision in a major migration: not all information necessarily needs to be transferred to the new system. Instead, the organisation should determine what the future of the information should be. Some information should be migrated for continued use, some should be archived, and some may be discarded following a controlled assessment. So when do you migrate documents to a new system, and when do you archive them?

The costly part is making the documentation usable in a new context 

The approximately 10 per cent of the documentation that was to be incorporated into the new system was first selected, and then it had to be prepared for a new way of being used. 

The aim of introducing the new system was to support the automation of parts of a process that had not previously been automated. This required more and more detailed data on the products covered by the documents. Key product information was already available in the organisation’s ERP system. The task was therefore to establish a logical link between the documents and the relevant information and to enrich them during the migration. 

Some of the documentation could be automatically matched with the information from the ERP system. However, the data quality and recording practices in the old document management system meant that the link could not be established automatically for all documents. Some documents therefore required manual preparation before the enrichment could be carried out in a controlled manner during the migration itself. 

In other words, it was not merely a matter of moving or adapting existing metadata from one field to another. The documentation had to be linked to information from another business system and brought up to a standard where it could be incorporated into new, automated workflows. 

The 10 per cent did not constitute a single, uniform set of documents. They consisted of several groups of documents, each with its own characteristics, peculiarities and enrichment requirements. The rules for selection, matching and adaptation therefore had to be defined separately for the different groups. 

This explains why a relatively small proportion of the total volume of documents could account for the bulk of the workload. The documents did not simply have to be transferred. They had to function correctly in the new context and support the purpose for which the new system had been established. 

This is one specific example, but the combination is a familiar one from our work on migrations: the new system must support a new or changed practice; data in the existing material is not necessarily sufficient for the new purpose; and only part of the documentation will continue to be actively used. This gives you an indication on whether to migrate a document to the new system or archive it. 

Expert insight with a high ‘hourly rate’ will help you save on document migration

In this case, it is worth paying a little attention to the client; Anja, an employee at our client’s organisation, sat down with us and used her in-depth professional insight to help us distinguish between the documentation that should continue to be used actively and that which should simply be retained. An employee can thus help you make a choice on what documents to migrate to a new system and what to archive.

Just think how much her time saved the organisation in consultancy fees to us. The organisation avoided spending resources on adapting, enriching, migrating and checking documents that were not to be used in the new system. Her actual ‘hourly rate’ on the project was therefore quite high. 

A technical analysis can show which documents exist, how large they are, and what metadata they contain. We external specialists can act on the basis of the insight and understanding we can provide. However, a deep business understanding of what the documents are used for, what documentary value they hold, and whether they should continue to form part of active processes must come from skilled people with professional insight into the material. 

In this case, that insight had a very tangible financial value. At the same time, it made it possible to focus the bulk of our efforts on precisely the documentation that needed to work well in the new system. 

Everything must be handled – but not in the same way 

In this specific case, there were two destinations for the documentation. The part that was to continue to be used actively was migrated to the new system, while rest was archived. In this particular example, there were no parts of the material that needed to be disposed of. 

In other contexts, controlled disposal may be a third option. This does not alter the fundamental principle: the entire volume of information must be managed, but it does not need to be managed in the same way. 

Documentation that is to continue to be used actively must function within the new system’s structure and work processes. It must be locatable, comprehensible and usable, and it must contain the data required by the new processes. Therefore, migration may involve selection, cleansing, transformation and enrichment. 

Documentation that is to be retained but not used in day-to-day operations serves a different purpose. It must still be retrievable and comprehensible, and it must be stored in accordance with the rules that apply to it. However, it does not need to be adapted to all the functions and workflows that apply in the active system, so this is usually less labour-intensive. 

Information that has neither continued practical value nor needs to be retained as documentation may be disposed of following a controlled assessment. This still requires a decision and a documented process. However, it does not require the information to be prepared for a new system first. 

The classification is therefore not a choice between taking the information with you or letting it go its own way. It is a way of ensuring that each part of the information set receives the treatment appropriate to its future function. 

A smaller volume can be processed more effectively; migrate what is active, archive what is needed

If all those several million documents had been processed with the same level of rigour as the active documentation, the scale of the task would have been entirely different. Within a fixed budget and time frame, the alternative might have been to reduce the quality of the processing in order to get through the entire volume. 

By first distinguishing between the documentation intended for active use and that intended solely for preservation, resources could be concentrated on the active part. Here, thorough work could be carried out on selection, data quality, enrichment and verification, so that the documentation could actually support the new workflows. 

The separation based on future function therefore did not merely reduce the scope of the migration. It made it realistic to process the most important documentation to a high standard and thus derive greater value from the new system. 

The separation can also create some space before go-live 

In fact, the separation also provided a little more flexibility in the project’s timetable. 

Projects can be under considerable time pressure in the run-up to go-live, and this was certainly the case here. Because the volume of information had been separated, efforts could be concentrated on the documentation that needed to be ready for active use in the new system from day one. 

Archiving and, where necessary, the controlled disposal of the remaining information can, in many cases – as here – be carried out at a later stage as part of the planned phasing out of the old system. This allows the remaining volume of information to be dealt with at a leisurely pace, without it putting a strain on the most critical part of the project’s schedule. 

However, ‘subsequently’ must not come to mean ‘indefinitely’ or ‘never’. The phasing out must be planned, and there must be accountability, resources and a clear end to the work. Otherwise, the old system may end up as a ghost that continues to be operated and incurs costs, even after the new system has been put into use. 

The right outcome is not necessarily to migrate as much as possible, but to archive what is possible 

A successful migration does not, therefore, necessarily mean that as much of the old system’s content as possible has been transferred to the new one. 

A successful outcome is when the information that is to be used going forward works effectively in its new context. Historical documentation that needs to be retained is archived securely. And information for which there is no longer a basis for retention is dealt with through a controlled decision-making process. 

This requires the organisation to review the information prior to migration and decide on its future. This professional assessment takes time, but the case also demonstrates just how much time it can save – and how significant an impact it can have on the quality of the new system. 

So does everything really need to be transferred to the new system? No. But everything must have a controlled future. 

The memberOf rule operator in Microsoft Entra ID stops functioning after 3 November 2026, and the failure mode is silence. Dynamic membership groups, dynamic administrative units and entitlement management auto-assignment policies that use it will not throw an error or disappear. They will simply hold their 3 November membership forever, so leavers keep access and joiners never get it. An outage gets noticed in minutes. A frozen access model gets noticed at an audit. 

Here’s what you should do before November 3. 

What did memberOf actually do? 

The preview let a dynamic group rule pull in the members of other groups: 

user.memberOf -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>']) 

It was the closest thing Entra ID had to nested groups that downstream services could read. Organisations used it to flatten a group hierarchy into something SharePoint, Teams, Conditional Access and group-based licensing could consume, because nesting has never worked cleanly for those consumers. 

Microsoft's stated reason for pulling it is scale. During the preview, memberOf was observed to slow dynamic membership processing across an entire tenant, not just for the groups using it. The alternative might be in development, but nothing is releasing yet. 

What will break, and where will you feel it first? 

Frozen membership propagates into everything downstream of the group: 

• SharePoint and Teams access. Leavers keep site and channel access. Joiners never get it. 

• Conditional Access targeting. New employees fall outside a policy scope they should be inside. Your MFA or device compliance policy silently stops covering people. 

• Group-based licensing. New starters go unlicensed. Departures keep consuming licences you pay for. 

• Access packages. Auto-assignment policies stop assigning and stop removing, so a time-bounded grant quietly becomes permanent. 

• Dynamic administrative units. Delegated admin scope drifts away from the org chart. 

For regulated organisations there is a second-order problem. If your access control procedure says membership is maintained automatically by an attribute-driven rule, and that rule has silently stopped evaluating, your documented process and your actual system state have diverged. That is an audit finding, and it is hard to bound afterwards. You have to prove who had access to what, and for how long. 

Which parts of the tenant do people forget to check? 

Almost everyone checks dynamic groups. Two other surfaces carry memberOf rules and almost nobody checks them: 

• Dynamic administrative units. Configured once by someone on the identity team, never touched again, and invisible during a normal access review. When one freezes, delegated admin scope stops tracking the org chart. 

• Entitlement management auto-assignment policies. The rule lives inside the policy's allowed-targets configuration rather than on a group object, so a group-focused export misses it entirely. 
  Both need Microsoft Graph to enumerate properly. Neither shows up if you search only the Groups blade in the admin center. 

The detail almost everyone misses: some of your memberships are already frozen 

Here is the finding that changes how you prioritise, and it comes straight from the preview's documented limitations. 

• memberOf never removed members when a source group was deleted, or when a member was removed from a source group. The documentation states it plainly: affected users remain members of the memberOf group until the rule is modified. 

Read that against the retirement notice. It means the 3 November freeze is not the start of your drift. If any source group referenced in one of your rules has been deleted, or has had members removed, some of your access is already stale today, and has been for as long as that source group has been gone. 
This is why a memberOf discovery exercise should resolve every source group ID in every rule and check whether it still exists. An unresolvable source group ID is not a data-quality annoyance, but a marker for access that stopped tracking reality some time in the past. That is exactly the kind of thing you would rather find yourself, than have found for you during an audit. 

How do you decide what to do with each rule? 

There are three honest outcomes, and a fourth that people avoid naming. 

Rewrite with supported operators. If the source groups correspond to a real attribute, such as department, job title, company name or an extension attribute, express the rule against that attribute directly. That could be considered the best outcome, and it usually forces an overdue conversation about HR data quality. 
Convert to assigned membership. Freeze the membership deliberately and manage it through your joiner/mover/leaver process. It is boring, auditable, and honest about who owns the list. 
Delete the rule. A meaningful share of preview-era groups turn out to serve nothing. 
Accept that some groups need a live union. This is the one people skip.This is the one people skip. If a group's membership only consists of all members in other groups, there is no attribute that expresses that. If it has to stay current, then assigned membership is not a migration.

How do you test a rewrite before you apply it? 

You want both your coverage and precision to be at 100%, but most migration plans only track coverage. 
Coverage is the share of current members the proposed rule still includes. Coverage below 100% means people lose access at cutover. You will hear about it the same morning. 
Precision is the share of the proposed rule's population that is a current member. Precision below 100% means people gain access at cutover. Nobody reports that, which is exactly why it is the dangerous one. 

A rule at 100% coverage and 80% precision looks like a clean migration on the day and is a silent over-grant forever after. When we built our own assessment tooling, we made precision the blocking threshold rather than coverage: the tool will not propose a rewrite that widens access, but it will happily propose one that leaves you a named list of eight people to add back by hand. A short manual task beats an invisible permission expansion. 

Whichever way you compute it, validate the candidate rule in the Entra portal before applying it, and compare membership before and after. 

A 3-step approach 

Step 1: find every use. Export dynamic groups and search the rules for memberOf. Do the same for dynamic administrative units and entitlement management auto-assignment policies via Graph. For each hit, record what consumes it: sites, teams, Conditional Access policies, licence assignments, access packages. The migration risk lives in the consumers, not the group object. If you need certainty and help, get in touch for a free assessment. 
Step 2: decide per group. Note the constraint that pushed people to memberOf in the first place: it could never be combined with other rules or operators. So a rewrite is rarely a like-for-like translation. It is a chance to express the intent properly. 
Step 3: validate and document. Compare membership before and after, confirm the downstream consumers still resolve, record the change. Under GxP, NIS2 or DORA the validation evidence is the deliverable. Leave buffer before 3 November. You do not want the last group migrated on the last day. 

Working with memberOf groups in a regulated environment?

We run a read-only assessment of your tenant and hand you the register, the per-group recommendation and the validation plan. Get In touch

I studied computer science, which is like a Swiss Knife in the IT-sector. During my studies, I learned the basics of almost everything IT, from coding to architecture to analysis. I decided to go to the job market with this solid all-round basis. I started at the Strator as a mix between a business-consultant, an analytic-consultant, and a technical-consultant. With time, I drifted over to the technical side.

I get mostly technical assignments now, which I’m happy about! My first long term project was a large data migration in which we had to extract the metadata and adapt it to the organisation-switch the client was going under. We had to reorganise and rename documents, execute the migration, and deliver an end-to-end report to ensure everything went as planned.

I really enjoyed getting to know the company we were working with. Typically, we investigate the data, the structure it has, the current state of things, etc. We’re trying to figure out what the company needs, and the reasoning. We get to do a bunch of nerdy analysis around data, and combine it with business development to get a lay of the land. Then, there is the technical aspect where you make flows, applications or software. It’s a lot of fun because you get to be technical and nerdy.

After about a year, the project was completed, and it was time for something new. Ulrich decided to take me under his wing, and taught me all about SharePoint. I spent almost all of 2025 learning all there is to know about SharePoint from a senior in the field. It gave me new skills and tools to use as a technical consultant

It’s nice to hear you were taught so much by your colleague. Is there a lot of support between colleagues?

On the rare occasions when we have a slow day, we always find something else to do by helping coworkers. It’s how we go about doing work pro-actively. Aside from that, I think we’re also good at taking care of everybody’s needs and differences. We’re good at embracing people and accommodating them. If anyone is ever a little low on work, we have no issue asking them to help with things either. It’s just how we do things.

This way we also get a pretty clear view of the strengths of the different people working here. It makes us able to really utilise their skills to the fullest, which in turn increases the number of services Strator can provide to a client. Dinah is a good example of this. She possesses a specific skill set and knowledge on how to classify data and files, and she does so with a specific kind of insight she gets from her background. That lead to the creation of the Strategic Information Management – Lite as a part of our Summer Clean-Up campaign. Especially right now, people could really use Dinah’s specific skill set. Making sure your data-landscape is clean and in order is getting more important by the day.

Do you experience those issues with unkept data landscapes a lot in the field?

It is one of those reoccurring issues we come across in the field. We often take on data migration projects in which the project manager, obviously, wants to be most efficient with the time allocated to the project. However, often times we see clients wanting to save time with a migration by forgoing an initial clean-up. We come into the project and are tasked with transferring large amounts of data from A to B, but we can’t complete our initial analysis as it should be, because the data isn’t structured, it’s not classified, or classified in an inconsistent way. The time constraint leads the clients to ask us to proceed with the migration anyway, but then we lose more time on the other side of the migration instead.

After the migration, we need to make sure all the data has been transferred properly, but if the original batch of data is in complete disarray, it takes way more time to cross reference everything. Aside from time, it also uses up way more of your data allowance to not clean up your data beforehand. When we do a clean-up we look for old, unused, empty and/or corrupted files which take up unnecessary space. Migrating them is completely pointless, and even unbeneficial for the client. Once migrated, the data might look nice because it is in a new UI, but it is still that same mess. Classifying your data would actually enable you to gain efficiency, and allow you to use new technologies to further develop your workflow.

On our end, Having a clean starting point makes it easier to reassure the client that all the work has actually been done correctly. If we are able to show the client one-to-one that the migration has been completed with an optimal structure, there is actual proof that everything is in order, compliant, and that nothing was lost. Carrying out an unstructured migration isn’t impossible, It just requires more resources because everything is less streamlined. Nine times out of ten, forgoing a clean-up of your old structure to try and save time, costs you more time and money in the end.

My advice for any reader would be: clean up your data before getting into a migration, and keep it clean after the migration as well. Do it yourself, have us do it, or someone else, because your data fills up quickly, and having a clean data landscape saves you a lot of time and money in the grand scheme of things, even outside of a migration.

Lastly, is there anything you’re looking forward to at Strator?

I’m looking forward to gaining more experience as a part of the sales team at Strator. I’m very excited to help the company reach greater heights and expand to work on bigger projects on larger scales. I would love to eventually help Strator expand and get bigger projects from big clients.

In this new series of Blogposts, we will introduce the people that make Strator what it is. With this first interview, we will be introducing Ulrich Bojko, our Head of Development, by asking him about his experiences at Strator. He shares insights on the importance of experts, reliance on AI, and digital sovereignty.

Since 2025, Ulrich has become a core part of Strator. Despite this relatively young cooperation, Ulrich has proven himself to be a valuable part of the team as a man of many ideas with a rigorous work-ethic and a lot of funny jokes. As a SharePoint expert and a business development enthusiast, Ulrich helps Strator reach a little further every day by developing new tools, carrying out massive migrations, and coming up with new ways in which Strator can help companies turn their information into a competitive advantage.

How did you get started at Strator?

My career at Strator started as an external consultant. I am a SharePoint expert and had been working with SharePoint Online and on-premises since 2008. I usually tell people that I can pretty much make SharePoint do anything that they want it to. I’ve made a ton of different solutions, from contract management and QMS systems to extranets and customer portals. Some of them were completely custom-coded, but more recently they have been based on SharePoint functionalities.

Either way, I started as an external consultant for Strator because clients asked them, “Well, now you have moved all of our data into SharePoint, so can you help us do other things with this SharePoint platform?” Of course, this is a completely different speciality, which is where I came in, and I fell in love with Strator and the people there.

When I first saw Strator, it struck me as probably the most boring company I’d ever been invited to. I mean, these librarian geeks talking about classification models and V-models and validation, and all these insane abbreviations like EQ, IQ, PQ, OQ, and whatnot. I thought, “How do you not just die a little inside every day from working with this? This is like a whole new level of geekiness.”

But once I really dug into it, I realised it wasn’t that boring. The moment you need to move 3 or 4 million files without losing any of them, while having it all under control and being able to prove that you did everything correctly, it starts becoming fun. I’m not only building technical solutions, but I’m also getting my hands dirty in the piles of data.

You’re currently the Head of Development. What does that mean?

I’ve always been fond of business development, even though I was a freelancer for 10–12 years. If I saw an opportunity, an issue, or a requirement at a company that I couldn’t solve, I always liked being the one with the network to do something about it. I also love talking to a lot of companies, not just clients.

When it comes to business development, I love developing ideas into real products or real offerings that a company can deliver, given the capabilities of the team. I just like seeing how we can package it, do sales, and build a network of clients, vendors, and partners. It’s about 50% of what I do, while the other 50% is solving clients’ SharePoint issues or building things for SharePoint.

I also follow European policy and politics quite a bit as part of the business development side of things. I like seeing opportunities in politics and pinpointing them for our business or our clients.

A lot of politicians are talking about digital sovereignty at the moment, for example, and it is something I have been talking about for the past 20 years. Now, with the shifts in the political climate around the US, the need for digital sovereignty is finally showing up on people’s radars. Every conversation between a vendor and a public-sector institution, municipality, ministry, government, or whatever will have digital sovereignty as number one on the agenda.

Good thing I love advising clients on how to achieve digital sovereignty: not by purchasing a licence, but by adapting certain capabilities. Especially when there are so many misconceptions about digital sovereignty caused by so-called “sovereignty washing,” where companies market their product as the magical button to becoming sovereign. People like swiping a card and believing they are digitally sovereign after five minutes. But suddenly, your new sovereignty-solution reaches a certain limit, requiring you to buy an upgrade, or the price just goes up. Before you know it, you’re stuck with a vendor lock-in and are no longer digitally sovereign. This can happen with both open-source solutions and, let’s say, a Microsoft solution. Making sure people see that is also what I want to do by building a network.

You really seem to enjoy guiding and advising as a part of business development.

I really like having that advisory role. These days, that comes with its own difficulties, though, as AI is often used as some kind of advisor. It’s quite risky because it’s very persuasive in guiding everybody towards the same one-stop-shop solution, since the big models are based on American thinking. You could get a European AI, but either way it is going to be based on some kind of model which will guide its answer. If people want actual knowledge, based on years of experience, they still need a person giving them personalised advice. I love doing that because advice is never a one-size-fits-all situation. I love getting familiar with a company and understanding its processes. All that business development, for Strator or for a client, is something I really enjoy. It allows me to use my technical knowledge and my communication skills. Operating between the tech and the boardroom is really where I’m most at home.

Is this over-reliance on AI something you encounter often?

That and the reliance on licensing to get everything in order instead of relying on actual capability or certain structures. AI is an extremely powerful tool, but it is just a tool. It doesn't work without the proper preparations.

People don’t want to focus on the boring parts, like getting their data in order first. That lack of a solid foundation is why you see statistics showing that somewhere between 70 and 95% of AI implementations or AI projects do not actually deliver the value they were expected to. People have stopped relying on specialists and experts because of all the marketing fluff, and because they don’t have time to go deeper. Besides that, AI will always answer in the way it thinks the prompter wants to be answered, which is why it cannot have the same value as an expert.

That is also some advice I would give to readers: think slow. AI is also a bubble, and it is important to know that it can pop. Companies can go bankrupt and AI services can increase in price drastically overnight. If you’re using AI without thinking about it too much, you might eventually start using AI instead of thinking. What do you do when the bubble bursts?

Be very, very careful when replacing people with AI. It is a handy tool that doesn’t have any critical sense, it doesn’t look beyond the parameters you give it, and it might not be as certain as you think it is. It can be the biggest digital sovereignty threat you can have because, suddenly, if it stops working or gives you wrong answers while your business depends on it, what do you do?

In short: think slow, build a workflow instead of only relying on AI, and hang on to those very valuable human values and capabilities in your team during this AI age.

Lastly, is there a project in the (near) future you are looking forward to?

Well, we've been developing these small tools for clients made to increase their digital sovereignty by helping them govern their SharePoint websites. I've been calling them our "Blueprints", and I am very excited to see them come to life. I've been working on a scan we will be using for our Strategic Information Assessment - Lite, and I will soon talk more about something I've been calling "Site Lifecycle Governance" as a part of these Blueprints. We are still working on the Blueprints, but we will release more news about them as time goes on.