Continuous assurance · For people and organisations

Shine light on change.
Know what needs attention.

Help people understand relevant trust and security changes. Help organisations turn identity, access and application signals into owned action and assurance.

Two clear experiences

Awareness for people. Assurance for organisations.

FOR INDIVIDUALSUnderstand relevant change

Plain-language guidance about meaningful signals, privacy boundaries and safe next steps.

Explore for individuals →
FOR ORGANISATIONSOwn the response

Specialist monitoring, detection engineering, incident operations and assurance across authorised systems.

Explore for organisations →
CONNECTEDUse the signals that matter

Use Vigilance independently or connect DiligenceID and Delegance signals around a broader trust journey.

PRIVACYObserve what is necessary

Use authorised operational signals for a defined purpose and avoid collecting unrelated personal or credential information.

The leadership issue

Most organisations have logs.
Fewer have operational assurance.

01

Signals are fragmented

Identity, access, application and credential events sit in different systems and schemas.

02

Alerts lack context

Teams receive technical conditions without the authority, resource or business impact needed to act.

03

Blind spots persist

Custom applications and delegated administration may sit outside standard SOC integrations.

04

Response varies

Ownership, escalation, containment and evidence can be reconstructed differently every time.

Operating model

From source signal to governed response—and measurable learning.

Vigilance connects collection, context and action. It does not equate more telemetry with better control, or an alert with an owned incident.

From signal to responseSignals are ingested, normalised and correlated before detections create alerts. Actionable alerts become owned incidents, responses and learning. Alert and incident are distinct stages.01SIGNALSIdentity · access · trust02INGESTGoverned collection03NORMALISEConsistent entities04CORRELATERelated activity05DETECTTested analytics06ALERTCondition to assess07INCIDENTOwner + severity08RESPONDContain + remediate09LEARNTune + assureFrom signal to responseSignals are ingested, normalised and correlated before detections create alerts. Actionable alerts become owned incidents, responses and learning. Alert and incident are distinct stages.01SIGNALSIdentity · access · trust02INGESTGoverned collection03NORMALISEConsistent entities04CORRELATERelated activity05DETECTTested analytics06ALERTCondition to assess07INCIDENTOwner + severity08RESPONDContain + remediate09LEARNTune + assure
An alert describes a condition requiring assessment. An incident is an owned investigation with severity and a response path.
Explore monitoring coverage →

What changes

Shorten the path from change to accountable action.

VISIBILITYKnow what changed

Correlate identity, privilege, authority and application events across control boundaries.

CONTEXTKnow why it matters

Enrich signals with identity, resource, delegation and business ownership so detection has something to reason about.

RESPONSEKnow who acts next

Assign severity, ownership, investigation and proportionate containment once a detection is confirmed.

ASSURANCEKnow what improved

Report coverage, recurring patterns, response evidence and unresolved control gaps to drive ongoing improvement.

Microsoft Sentinel

A major platform for identity-centred monitoring.

MAITS can bring Microsoft Entra signals, directory events, access changes, application telemetry, custom systems and credential lifecycle events into Sentinel.

Normalisation and identity context make correlation possible; analytics, incidents and runbooks create an operational path. Vigilance can also use the monitoring platform that fits the organisation’s sources and operating model.

Explore the Sentinel model →
How identity signals become operational monitoringSignals from identity systems, applications, digital credentials, Delegance and custom systems move through supported collection and normalisation into Microsoft Sentinel or another selected monitoring platform, analytics, alerts and incidents.01SIGNAL SOURCESIdentity · apps · trust02CONNECTORS / INGESTSupported collection03NORMALISEEntity + event context04MONITORING PLATFORMSentinel or selected tool05ANALYTICSDetection hypotheses06ALERTS / INCIDENTSAssessment + ownershipHow identity signals become operational monitoringSignals from identity systems, applications, digital credentials, Delegance and custom systems move through supported collection and normalisation into Microsoft Sentinel or another selected monitoring platform, analytics, alerts and incidents.01SIGNAL SOURCESIdentity · apps · trust02CONNECTORS / INGESTSupported collection03NORMALISEEntity + event context04MONITORING PLATFORMSentinel or selected tool05ANALYTICSDetection hypotheses06ALERTS / INCIDENTSAssessment + ownership
Microsoft Sentinel is a major supported implementation platform, not a mandatory dependency for every Vigilance engagement.

Custom connectors

Observe the systems standard integrations miss.

How custom signals enter monitoringREST APIs, webhooks, Event Hub, Log Analytics, syslog and polling patterns produce normalised security signals for monitoring and detection.SOURCES / PATTERNSCONTROLOUTCOMESREST APIWEBHOOKEVENT HUBLOG ANALYTICSSYSLOGPOLLINGVIGILANCENormalised signalSchema · entity · timeMONITORINGDETECTIONHow custom signals enter monitoringREST APIs, webhooks, Event Hub, Log Analytics, syslog and polling patterns produce normalised security signals for monitoring and detection.SOURCES / PATTERNSREST APIWEBHOOKEVENT HUBLOG ANALYTICSSYSLOGPOLLINGVIGILANCENormalised signalSchema · entity · timeOUTCOMESMONITORINGDETECTION
MAITS selects and engineers the ingestion pattern around each source interface and operating requirement.

MAITS confirms the source interface, security model and operational requirements, then engineers the ingestion and support path around that system.

Understand connector engineering →

Identity and trust detection patterns

Detect changes that alter trust or authority.

PRIVILEGE

Unexpected administrator assignment

RECOVERY

Unusual identity recovery

DELEGATION

Authority outside expected scope

CREDENTIALS

Issuance or revocation anomaly

APPLICATION

Abnormal administration activity

ENTITLEMENT

Excessive access change

Each detection is mapped to available telemetry, a tested baseline, an accountable owner and a proportionate response.

Explore detection design →

Alert ≠ incident

An alert describes a condition. An incident owns the response.

How an alert becomes an owned incidentA signal matches a detection and creates an alert. Assessment branches to close and tune when it is not actionable, or to an owned incident, response and learning when it is actionable.SIGNALDETECTIONALERTASSESSMENTNOT ACTIONABLECLOSE / TUNERetain evidenceACTIONABLEINCIDENTOwner · severity · contextRESPOND + LEARNAlert and incident decision pathSignal, detection, alert and assessment are stacked. Assessment branches to close and tune or to an owned incident and response.SIGNALDETECTIONALERTASSESSMENTCLOSE+ TUNEINCIDENTOwnedRESPOND + LEARNContain · remediate · improve
Alerts require assessment. Incidents require ownership, severity, an accountable response and closure evidence.

Runbooks can enrich, notify, ticket or act automatically. High-impact response can retain human approval.

Explore incident operations →

Managed service

Maintain observability as the environment changes.

ONBOARD

Signals and connectors

Assess sources, implement ingestion and maintain monitoring coverage.

DETECT

Analytics and tuning

Map detections to risk, test them and refine with operational evidence.

RESPOND

Incidents and runbooks

Structure ownership, investigation, escalation and proportionate action.

REPORT

Executive assurance

Explain high-risk events, control gaps, recurring patterns and unresolved exceptions.

MAITS product family

Evidence. Authority. Assurance.

VIGILANCEContinuous assurance

How do we know when trust or access is at risk?

Frequently asked questions

Monitoring claims, kept precise.

What service model does Vigilance use?

Vigilance provides specialist monitoring and operational assurance for identity, access, applications and digital trust. Support hours, response ownership and service levels are agreed for each engagement.

Is Microsoft Sentinel required?

No. Sentinel is a major MAITS implementation platform, but the monitoring platform is selected for the organisation and engagement.

Are the listed detections prebuilt?

No. They are candidate detection patterns. Each requires available telemetry, implementation, testing, tuning and an owned response.

Does credential monitoring require complete credential contents?

No. Operational signals can cover issuance, verification, status, revocation, configuration and service health without collecting complete credential contents.

Next step

Start with the risks you cannot currently see.

Bring the identity systems, critical actions, current telemetry and response ownership. MAITS can map the observability gaps.

Discuss Vigilance →