NIS2 and DORA — compliance of the Microsoft environment

The analysis translates the obligations under the Czech Cybersecurity Act No. 264/2025 Coll. (NIS2) and the DORA regulation into specific Microsoft 365 and Azure settings. The output is not a yes-no table but the specific setting that is missing and the order in which to fill the gaps.

Price

from 75,000 CZK

Output

within 4 weeks of getting access

Scope

the cloud environment only

Scope of the analysis

What the analysis covers

Eight areas of obligation; for each of them we look for its reflection in a specific Microsoft 365 or Azure setting. Anything with no reflection in the cloud is marked as out of scope — and that is information, not a gap.

Defining the regulated servicesWhich services are in scope and where they run. You supply this input in writing; without it the scope spreads and the analysis has nothing to stand on.
Identity and access managementMapping the obligations onto the actual configuration of accounts, roles, approvals and periodic access reviews in Entra ID.
Multi-factor authenticationWhich methods are enforced, where the exceptions are and whether the resistance matches what the regulation asks of you.
Incident detection and reportingWhat is actually detected in Defender and Sentinel, how an incident arises, who reports it onwards and whether the statutory deadlines can be met.
Logging, retention and evidenceWhich records are kept and for how long, and whether compliance can be evidenced by an export rather than by a claim.
Data protection in the cloudEncryption, classification and loss prevention to the extent that can be configured in the tenant.
Continuity of cloud servicesWhat the Microsoft services back up themselves, what you have to arrange and what would really be missing after an outage.
Suppliers and the register of informationWhich entries in the register of information can be obtained directly from the cloud environment and which you have to fill in from elsewhere.
What the analysis does not include

Everything outside Microsoft 365 and Azure. Your own servers, the office network, endpoints outside tenant management, industrial and operational technology, third-party applications and the paper side of compliance are not in scope and the analysis says nothing about them. Nor does it cover the legal assessment of whether the act applies to you, organisational measures and policies, impact analyses, continuity plans, penetration tests and contractual relationships with suppliers.

Inputs

What we need from you

  • An account in your environment — either a guest invited into your tenant, or one you create in it. One is enough, it has read access only and you remove it at handover.
  • Read access over the tenant to the same extent as for hardening.
  • Read access over Sentinel, if logging and retention are to be evidenced.
  • The list of regulated services in writing. The input without which we cannot start.
  • A contact for the person responsible for compliance, by name. Often it is nobody from IT.

How we treat your environment and data →

The list of regulated services is required before the start, not along the way. It is the only way to keep the price fixed.

Deliverables

What you get

  • A mapping of obligation → measure → specific setting → status → gap, within the scope of the cloud environment.
  • A priority and an effort estimate for every gap. That is exactly what separates a usable output from a yes-no table.
  • A roadmap ordered by severity.
  • An evidence pack — what can be exported as proof of compliance for the regulator or for a customer questionnaire.
  • A list of obligations out of scope, so that it is in black and white what remains to be solved elsewhere.
  • A PDF report, a simple summary for the board and a handover record.

How it runs

How it runs

Intro call

Thirty minutes. We get to know each other and settle which regime of obligations you are in, which services you consider regulated and who is responsible for compliance.

Defining the scope

A written list of the regulated services and read access.

Analysis and mapping

Configuration is collected and mapped onto the obligations. No impact on operations.

Handover

A presentation of the mapping and the roadmap to the responsible person and to the board.

Frequent questions

What people ask most often

Does this mean we will be compliant after the analysis?
No. The analysis covers the Microsoft 365 and Azure environment only. Compliance with the Cybersecurity Act and with DORA is not about the cloud alone — it includes processes, contracts, people, your own infrastructure and operational technology. Bearclave cannot vouch for the rest, and the output therefore includes an explicit list of what is out of scope.
Will it tell me whether the act applies to me?
No. The act rests on self-identification and that is your decision, one a lawyer should help you with. The analysis picks up behind it and deals with how to meet the obligations technically in the cloud.
We have a gap analysis on paper from a consultancy.
Then we build on it rather than doing it again. A paper analysis typically ends with the finding that something is missing. This one says which specific setting it is and how much effort it takes to add it.
We need both the Cybersecurity Act and DORA. Is that twice the work?
It is not. The mapping differs, but the data collection is the same. Doing both at once is considerably cheaper than two separate engagements.
What if an obligation has no reflection in our cloud environment?
It is marked as out of scope. That is not a gap in the analysis but information that you have to solve it organisationally, contractually or on your own infrastructure. Knowing where that boundary runs is part of what you are buying.

Not sure where you stand in the regulation? Half an hour will tell

All we need to know is which regime of obligations you are in and which services you consider regulated.