Managed Security Operations Center (SOC) fOr Microsoft 365 AND Azure
NIS2 Regulatory Context
NIS2 Is Now in Effect. Monitoring Is No Longer Optional.
Since December 2025, NIS2 implementation legislation has applied to more than 30,000 organizations in Germany. The requirements are immediate: documented incident detection, defined response procedures, and verifiable reporting capabilities. Organizations that cannot demonstrate an active security monitoring process face regulatory exposure - and in many cases, personal liability for management.
Building an internal SOC to meet these requirements demands significant investment in personnel, technology, and process development. For most organizations operating Microsoft 365 and Azure environments, the faster and more reliable path is a managed security operations model that integrates directly into the existing Microsoft stack.
Centralized Components
24/7 Monitoring & Incident Response – without Vendor Lock-in
A SOC is only effective if it works in real-world operations: clear escalation procedures, well-defined responsibilities, robust use cases, and transparent decision-making—even at night and on weekends.
24/7 Investigation & Triage
Qualified analysis of security-related incidents. Clear classification based on severity and escalation to designated on-call teams.
Incident Response (IR)
Technically integrated with Microsoft Defender & Sentinel. Containment-focused immediate responses using repeatable playbooks instead of ad-hoc measures.
Threat Intelligence & Hunting
Proactive search for new attack techniques. Threat intelligence-driven prioritization with purple team validation.
Detection Engineering
Maintenance and further development of detection use cases and SOAR playbooks.
How It Works: 3-Step Process
From theFirst Conversation to Active Monitoring in Three Steps
Step 1: SOC Readiness Assessment
We analyze your Microsoft environment: which log sources are relevant, which use cases are appropriate for your threat profile, and which escalation paths actually exist in your organization. This assessment forms the basis for all subsequent configuration decisions.
Step 2: Detection Engineering & On boarding
We configure Microsoft Sentinel and Defender XDR according to the use cases identified in the assessment. Detection rules, SOAR playbooks, and escalation procedures are documented and activated within your tenant - not on an external platform.
Step 3: Managed Operations
Your environment is monitored 24/7. The SOC team investigates alerts, classifies incidents by severity, and responds according to defined playbooks. Regular reporting gives you full visibility into security events, response actions taken, and open recommendations.
without VENDOR LOCK-IN
Administrative access based on security requirements
Data sovereignty in your hands
Logs, workspaces, and decisions are all within your environment
Content that can be incorporated
Use cases, playbooks, and escalation paths are documented and ready for handover
Transitions scheduled
Switching providers, setting up an in-house solution, or running systems in parallel are part of the model, not exceptions
Companies that trust us:
Whitepaper
HIGH-QUALITY DETECTION INSTEAD OF DEPENDENCE ON A SINGLE SUPPLIER.
What are the five pitfalls to watch out for when choosing a SOC service provider, and which contract clauses help maintain or relinquish control? For CISOs and IT managers evaluating external monitoring services or reviewing existing contracts.
Frequently Asked Questions
FAQ
What happens if we decide to set up the SOC internally at a later date?
We will then hand over all playbooks, detection rules, and documentation in your Sentinel/Defender tenant; your data will remain in your environment regardless. A structured exit is not a matter for negotiation with us, but rather part of our operating model—we do not want to recreate the very vendor lock-in risk we warn you about.
How does this differ from a traditional MSSP?
Traditional MSSPs import your logs into their proprietary platform and issue tickets—with us, you retain control over your data and architectural decisions; we manage your Microsoft stack directly within your tenant. The key difference is transparency: You can see at any time which use cases are active, how decisions were made, and what steps were necessary, rather than receiving black-box alerts.
Do we need a new SOC for this, or will our existing one work?
Integration possible, with a focus on use cases and escalation procedures
What is the difference between SOC, SIEM, and MDR?
A SIEM (Security Information and Event Management) is a software system that collects and analyzes security data from across your environment. A SOC (Security Operations Center) is the team of analysts that operates the SIEM around the clock, evaluates alerts, and responds to incidents. MDR (Managed Detection and Response) describes the outsourced service model in which an external provider takes responsibility for detection and response. A managed SOC combines all three: SIEM technology, ananalyst team, and an MDR service model - from a single provider operating inside your Microsoft tenant.
Which Microsoft licenses are required for a managed SOC?
The core capability set requires Microsoft Defender XDR (included in Microsoft 365 E5 or purchasable as anadd-on) and Microsoft Sentinel (consumption-based licensing via Azure). Depending on your environment, Defender for Identity, Defender for Endpoint, and Entra ID P2 may also be relevant. We assess your current licensing position during the readiness assessment and identify any gaps before onboarding begins.
Does this only work with Microsoft Defender/Sentinel, or does it work with other tools as well?
Our focus is on the Microsoft Security Platform (Defender XDR, Sentinel, Entra) because it offers the deepest integration and best API connectivity for true response—we are not a “one-size-fits-all” generalist. However, if you have meaningfully integrated additional specialized tools (e.g., for OT, specific cloud workloads), we incorporate these into the detection logic and incident response processes.
How does cycura's SOC address NIS2 reporting requirements?
NIS2 requires organizations to notify the relevant authority within 24 hours of becoming aware of a significant incident, and to submit a detailed incident report within 72 hours. Our SOC provides the detection capability, incident classification, and documentation needed to meet these timelines. Monthly reporting gives you an auditable record of security events and response actions - structured specifically for regulatory and board-level reporting.
What happens during an active security incident?
When the SOC detects a confirmed incident, the response follows a documented playbook: initial triage and severity classification, containment actions executed directly within your Microsoft environment (isolation, account suspension, policy enforcement), notification to your designated on-call contact, and a post-incident reportdetailing timeline, actions taken, and recommendations. Response speed is governed by SLAs set at contract stage - not by ad-hoc availability.
SOC support?
The starting point isn’t the decision that “we need an SOC,” but rather a structured assessment: Which sources are relevant? Which use cases are appropriate? What escalation capabilities actually exist?