Secure your SAP environment before, during, and after migration

We are the security operations and infrastructure security partner to your SAP programme. We are not your SAP application security specialist, and you should be suspicious of anyone who claims both.

Your basis team owns what happens inside SAP: roles and authorisations, transports, RFC and gateway configuration, the application audit log. Your hyperscaler owns the platform beneath the operating system. Your integrator owns the conversion.

What sits between them, and what none of the three contracts to run for you, is the security operations layer: an independent review of the target architecture and its access paths, configuration hardening measured against published benchmarks, the SIEM build and the detection content that goes into it, and 24/7 monitoring and response across the identity, endpoint, cloud-infrastructure and network telemetry your SAP systems depend on.

That is a real gap on most migration programmes. It is also a narrower claim than this page used to make.

No. Logs are aggregated and stored inside your own Microsoft Azure environment. You own the workspace, you own the subscription, and you pay Microsoft directly for ingestion and storage rather than paying a vendor to hold your data.

Analysts reach the data by being granted delegated administrative access into your tenant, not by your data being exported into a vendor-owned lake. The same is true of the Sentinel instance when we build it ourselves: it is built in your Azure subscription, within a single directory.

This is the part of the service that survives the hardest legal review, so it is worth saying precisely: the data does not move, the access does.

The infrastructure underneath, unless you deliberately scope more. This is the question the page previously answered badly, so here it is plainly.

What is monitored as standard is identity and authentication, endpoint and server telemetry, cloud infrastructure activity, and the network perimeter. The service requires a minimum of three qualifying collection source types before it will carry a service level at all — endpoint visibility, user authentication and access, and host address resolution — and an ERP application log is not one of them. Under the Microsoft-native-only variant, non-Microsoft sources cannot be ingested at all.

SAP’s own logs can be brought in, as a custom source: a connector and a parser built for your estate, detection content written against it, scoped and priced as its own piece of work. And this matters — a log source sitting in your Sentinel workspace that has not been subscribed for monitoring is explicitly out of scope for alerting and investigation. “Your SAP logs are in Sentinel” and “your SAP is monitored” are two different statements. Make every supplier you talk to say which one they mean.

On the commitment: the contracted service level is a single Time to Respond — 15 minutes, the same for every severity — measured from the creation of an incident in the platform to the completion of initial triage and classification, with the automated part of that workflow included in the measurement. It commits to how fast an alert becomes a classified incident, not to when you are told and not to containment; notification and escalation are agreed in the order rather than contracted. There is no contracted time-to-detect either — nobody can honestly sell you one. And remediation and recovery are yours to execute; we investigate, classify, advise and guide.

By being sequenced against it in the order, rather than discovering it afterwards — and there is one specific clause you need to know about before you sign anything.

Monitoring contracts require your log sources to be onboarded and integrated within 30 days of the SOC go-live date. A source that needs longer pushes the work into a separate consulting agreement. So a freeze that runs longer than a month, or a monitoring contract signed well ahead of cutover, collides directly with that clock. It is entirely manageable, but only if the SOC go-live date is chosen deliberately against your freeze windows at the point of ordering.

What we will not do is invent a mechanism. We have genuine cutover programme experience — cutover planning, cutover governance and a responsibility matrix across SAP core, satellite and infrastructure workstreams on large transformation programmes — but that is programme management, not a documented security-during-freeze procedure. We would rather tell you where the contract bites than describe a process we have not written down.

Yes, we will write it down, and we do not have a pre-built answer to hand you before we have looked.

What the contract shape already fixes: you provide and pay for the platform licensing and the cloud consumption; you enable logging on in-scope systems and make the network changes needed to route those logs; and service levels do not apply to outages of third-party SaaS or cloud infrastructure providers. The direct consequence for a RISE landscape is that any component whose logs we cannot reach, or whose provider is itself down, sits outside any commitment we are able to make. We would rather state that than let it emerge during an incident.

The deliverable we would hold ourselves to is a source-by-source list: what is in scope and monitored, what is ingested but not subscribed, and what belongs to SAP or the hyperscaler rather than to us. On a shared-responsibility landscape that list is worth considerably more than an architecture diagram, and it is the document to ask every bidder for.

Artefacts, not assurances. The assessment output and its gap register; hardening reports measured against published benchmarks, which state the benchmark and the result rather than asserting a posture; the detection and response runbooks; and the monitoring scope statement described in the previous answer, which is often the single most useful page in the file because it says what is and is not covered.

Two supporting facts. Spirity holds ISO/IEC 27001 certification as a managed security service provider, so the service is delivered from a certified operation. And our advisory practice produces the readiness work itself — posture and compliance assessment, policy and procedure development, gap identification and remediation planning against NIS2, DORA and ISO 27001.

What we will not tell you is that this makes your SAP estate “not a gap” in your evidence. Under the monitoring contract, log archiving for compliance and regulatory purposes is your responsibility, obfuscating protected data before it reaches the SOC is your responsibility, and the provider disclaims responsibility for your compliance with log collection and retention regulation. We contribute evidence and close control gaps. We do not certify the estate, and any supplier who says otherwise has not read their own contract.

More relevant, if anything. The page is written around migration because that is when an SAP estate changes fastest and its access paths are most exposed, but only one of the workstreams is genuinely migration-shaped.

Hardening, monitoring, incident readiness and compliance alignment are steady-state services. A post-migration estate has the additional problem that the temporary arrangements made during the programme — the extra privileged accounts, the interim network paths, the firewall rules opened to get through cutover — usually outlive the programme that created them, and nobody is left who remembers which were meant to be temporary.

The sensible entry point is the same either way: the assessment first, so that what follows is scoped against your estate rather than against a template.