01
What the product does
The exact source types, event detail, investigation fields and retention depend on the selected connector and service tier.
Guardian security operations product
Know which security sources are healthy, which alerts matter and what was investigated.
Guardian Security Monitoring provides a connector-neutral operating layer for agent, collector and log-source health, security events, alert lifecycle, investigations and customer actions.
Australian data residency
Guardian for Australian customers is built, operated and hosted in Australia. All Guardian customer and platform data, including backups and recovery copies, is maintained and stored within Australia.
Connector-neutral monitoringAgent and source healthAlert and investigation lifecycleProvider and customer views
Buyer decision summary
Know what Guardian Security Monitoring does, what the customer sees and what Damocles is responsible for before activation.
Guardian retains supported source references, timestamps, source state, alert and investigation lifecycle, disposition, linked assets or users, evidence references, actions and escalation history. Customer views expose only allow-listed information.
The proposal identifies monitored endpoints, users, sources, collectors, ingestion, retention, connector, customer users, provider relationship and service coverage. Platform-only, provider-operated and Aegis-managed options can therefore be priced and supported differently.
Guardian does not imply unlimited ingestion, retention, source coverage, rule development, 24×7 monitoring, incident response or detection of every malicious event.
02
What the customer sees
Technical console detail remains available to authorised operators while Guardian provides a consistent customer experience.
03
What Damocles manages
The customer can use Guardian with its own team, through an MSP, or with Aegis managed defence.
The operational problem
A monitoring platform can ingest millions of events and still leave the customer unsure whether the right sources are connected or the important alerts were handled.
Security monitoring fails operationally when agents stop reporting, collectors are misconfigured, customer ownership is unclear, alert queues are noisy or investigation conclusions remain trapped in a specialist console.
Guardian separates the public product from any one underlying platform. Supported connectors provide source and event data; Guardian provides customer scope, source health, alert and investigation records, actions, evidence and reporting. Aegis adds the Damocles analyst service where selected.
01
See the monitoring gaps
Identify expected, configured, healthy, stale, zero-data, degraded and unavailable sources instead of treating silence as security.
02
Follow the alert lifecycle
Present customer-scoped severity, status, priority, disposition, linked assets and investigation context.
03
Drive a clear response
Turn confirmed activity into an escalation, incident pathway, risk or All Action with ownership and evidence.
Product capability
A customer and provider operating model above compatible security-event platforms.
The exact source types, event detail, investigation fields and retention depend on the selected connector and service tier.
AG
Agent and endpoint health
Track approved endpoint agents, last-seen state, protection relationship and customer mapping where supported.
CL
Collector and integration health
Monitor collectors, gateways, APIs and integration jobs required to move security data.
LS
Log-source inventory
Record expected firewalls, identity, cloud, endpoint, server and application sources and their reporting state.
AL
Alert lifecycle
Normalise supported alerts into consistent severity, status, priority, source, affected scope and timestamps.
IV
Investigation context
Present customer-safe investigation title, priority, status, disposition, evidence and linked records.
AC
Actions and escalation
Connect required response to owners, due dates, risks, All Actions and the agreed escalation path.
What the customer sees
Customers see whether the service is functioning and what requires their action.
Technical console detail remains available to authorised operators while Guardian provides a consistent customer experience.
OV
Security Operations overview
Source health, open alerts, active investigations, vulnerability context, actions and approved reports.
SH
Source-health view
Expected sources, last-seen state, zero-data, degraded and unavailable conditions with practical context.
AQ
Alert queue
Customer-scoped alerts with source, severity, priority, status, affected assets or users and investigation linkage.
ID
Investigation detail
Customer-readable summary, timeline, disposition, evidence and required action without unrelated tenant or analyst-only data.
RP
Operational reporting
Monitored scope, source health, alert and investigation movement, escalations and unresolved actions.
PV
Provider operations
Authorised customer switching, source mapping, health review, escalation and reporting through provider-scoped relationships.
What Damocles manages
Damocles can manage the platform, connector and analyst operations as separate service layers.
The customer can use Guardian with its own team, through an MSP, or with Aegis managed defence.
CO
Connector onboarding
Configure source authentication, customer mapping, field translation, health checks, synchronisation and safe failure behaviour.
SI
Source inventory
Confirm expected sources, ownership, data path, log type, reporting state and customer escalation contacts.
RT
Rule and tuning support
Maintain approved detection, suppression, enrichment and routing logic where the selected platform and service include it.
MO
Monitoring and triage
Aegis analysts review source health and security signals during the contracted coverage window.
IN
Investigation and escalation
Investigate material activity using authorised context and escalate through the agreed customer or provider pathway.
SR
Service review
Review source gaps, alert quality, investigations, tuning, open actions and reporting with the customer or MSP.
Operating lifecycle
From source onboarding to investigation, escalation and service improvement.
Platform capability and analyst coverage remain explicit so the customer knows what Guardian shows and what Damocles operates.
01
Scope sources
Confirm the expected agents, collectors, platforms, log types, retention and customer ownership.
02
Connect and baseline
Onboard the supported connector and establish expected source health and common activity.
03
Monitor
Track source health and receive supported security events and alerts.
04
Triage
Prioritise material activity using source, asset, identity, vulnerability and customer context.
05
Investigate and escalate
Gather authorised evidence, record the conclusion and invoke the agreed response path.
06
Close and improve
Track actions, review outcomes, tune approved logic and resolve source or service gaps.
Common use cases
Common security-monitoring operating models.
The product does not require one platform brand; the implementation is selected according to the customer architecture and service model.
EX
Existing customer platform
Connect a supported customer security-event platform and use Guardian for customer views, actions and reporting.
MS
MSP-operated monitoring
Allow the MSP to retain first-line monitoring and customer communication while Guardian provides scoped operations and reporting.
AE
Aegis managed defence
Add Damocles monitoring, triage, investigation and escalation to the selected compatible platform.
SH
Source-health assurance
Use Guardian to identify missing or stale sources even where another team performs the alert analysis.
HY
Hybrid architecture
Combine different supported source platforms or regions while preserving customer scope and common Guardian records.
TR
Technology transition
Maintain the Guardian customer workflow while the underlying event platform or connector is changed through an approved migration.
Operating model
How Guardian Security Monitoring is onboarded, integrated, evidenced and scoped commercially.
These details remain explicit before activation, but are grouped into one operating view so buyers can review the responsibilities without working through four separate page sections.
ON
Onboarding and implementation
Implementation starts with an expected-source register and a clear analyst responsibility model. Damocles documents the customer, provider relationship, expected agents and log sources, source owners, data paths, retention, selected connector, available fields, service contacts and escalation levels. The first objective is to know what should be reporting before alert volume is treated as meaningful. Sample alerts and investigations are reviewed to confirm customer ownership, severity mapping, safe field exposure, disposition, evidence and action linkage. Unsupported fields or source limitations are documented before go-live. For managed monitoring, onboarding also defines coverage hours, triage rules, investigation depth, escalation contacts, response responsibilities, service review and the boundary between the customer, MSP and Damocles.
IN
Connector and integration model
Compatible connectors allow the public product to remain stable as security technologies evolve. A security-monitoring connector must expose source health, customer ownership, supported alerts or events, stable identifiers, lifecycle state and safe error information. Guardian does not treat browser-supplied tenant identifiers or fuzzy naming as customer authority. The selected implementation can be commercial, self-hosted, provider-operated or customer-operated where a supported connector and operating model exist. The proposal identifies the specific connector and licensed features without making that vendor the public product. New connector requests are reviewed for API maturity, tenant isolation, source-health capability, event volume, rate limits, retention, investigation fields, evidence handling, supportability and engineering effort.
EV
Data, evidence and reporting
Customer records remain traceable without exposing credentials or raw upstream event payloads. Guardian retains supported source references, timestamps, source state, alert and investigation lifecycle, disposition, linked assets or users, evidence references, actions and escalation history. Customer views expose only allow-listed information. Source-health and service reports use persisted state. An unavailable connector, stale source or failed synchronisation is shown explicitly rather than converted into a healthy zero-alert result. Investigation evidence and analyst-only notes remain role scoped. Customer reports explain what was monitored and concluded without revealing unrelated tenants, credentials, internal platform identifiers or unsafe raw payloads.
CM
Commercial unit and responsibilities
Commercial scope separates platform capacity, connector work and analyst service. The proposal identifies monitored endpoints, users, sources, collectors, ingestion, retention, connector, customer users, provider relationship and service coverage. Platform-only, provider-operated and Aegis-managed options can therefore be priced and supported differently. Aegis coverage hours, triage, investigation, escalation and reporting are service commitments. They are not automatically included simply because the customer has a connected security-monitoring platform. The customer and MSP remain responsible for the systems, authorised access, source deployment, response authority and remediation allocated to them. Incident response, forensic acquisition and engineering are separate unless listed in the service schedule.
Frequently asked questions
Questions buyers ask about Guardian Security Monitoring.
The exact answer is confirmed in the proposal and package schedule, but these points should be understood before activation.
Q1
Can Guardian connect to our existing SIEM or monitoring platform?
Yes where a supported connector exists and the required customer mapping, source-health and lifecycle fields are available.
Q2
Does Guardian replace the underlying monitoring platform?
No. The selected platform performs event collection and analysis. Guardian provides the customer, provider, action, evidence and reporting layer.
Q3
Can Damocles operate the service?
Yes through Aegis, with the coverage, sources, triage, investigation and escalation stated in the service agreement.
Q4
Can an MSP keep first-line responsibility?
Yes. The MSP and Damocles responsibility split is defined before onboarding and reflected in the provider and customer workflow.
Q5
What if a source stops reporting?
Guardian shows the stale, zero-data, degraded or unavailable state and can create follow-up rather than presenting a false clean result.
Q6
Is incident response included?
Only where expressly contracted. Monitoring and escalation do not automatically include unlimited containment, forensics or recovery engineering.
Scope and boundaries
Coverage depends on the connected sources, platform capability and contracted operating service.
Guardian does not imply unlimited ingestion, retention, source coverage, rule development, 24×7 monitoring, incident response or detection of every malicious event.
Unsupported source types, missing customer authority, incomplete fields, connector outages and unlicensed platform features remain explicit limitations.
The public product remains vendor neutral, but the proposal must identify the selected implementation, connector, quantities, service responsibilities and support boundaries.
Take the next practical step
Review the sources, platform and analyst responsibilities required for a useful security-monitoring service.
We will map the expected sources, current technology, connector options, source health, alert lifecycle, investigation depth, escalation and service coverage.