Website Security Monitoring: Which Alerts Matter, Who Responds and What Happens Next
Many websites already generate security alerts.
An administrator receives failed-login emails. A hosting dashboard reports a spike in traffic. A plugin says files changed. A scanner identifies outdated software. The backup service reports success most days and failure occasionally. Application errors sit in another log.
That can look like monitoring. It may be little more than noise.
Security monitoring is a system that:
- records useful events
- protects enough evidence to investigate them
- detects conditions that matter to the organisation
- sends alerts to an available owner
- provides a repeatable triage and response path
- improves after false positives, missed events and incidents
If an alert reaches an unattended inbox, uses no business context or has no authorised action behind it, the organisation may know something happened without becoming safer.
The objective is not to collect every possible log or send more notifications. It is to detect credible threats early enough to act, while retaining the evidence needed to understand scope and recover responsibly.
Monitoring is different from scanning
These activities overlap but are not interchangeable.
Availability monitoring
Checks whether a website or function responds. It can detect outages and obvious defacement but may not detect a silent compromise.
Vulnerability scanning
Looks for known weaknesses, outdated software or insecure configuration. It identifies exposure, not necessarily active exploitation.
Malware or file scanning
Looks for known malicious patterns or unexpected file changes. It can miss novel or database-only compromise and may flag legitimate deployments.
Event logging
Records actions and system conditions, such as authentication, administrator changes, requests, errors and integration outcomes.
Threat detection
Applies rules, context or analysis to events to identify suspicious behaviour requiring investigation.
Incident response
Validates the event, contains harm, preserves evidence, removes the cause, restores service and handles business consequences.
A complete programme can use all six. Buying one scanner does not create an incident-response capability.
Begin with the website’s risk and architecture
Monitoring should reflect what the website does.
Ask:
- Does it collect personal information?
- Does it process ecommerce orders or payments?
- Can users log in?
- Does it expose a customer, member, dealer or staff portal?
- Which administrators and agencies have access?
- Which plugins, apps and APIs extend it?
- Which systems receive leads, orders or customer data?
- What revenue or operations stop when it is unavailable?
- What regulatory, contractual or insurance obligations apply?
A brochure site and a customer portal should not share the same detection priorities.
Create an architecture inventory covering:
- domain and DNS
- CDN, WAF and edge
- hosting and network
- operating system and runtime
- web server and database
- CMS and ecommerce application
- themes, plugins and custom code
- identity and administrators
- third-party integrations
- backup and deployment systems
- data stores
Monitoring gaps often appear at the boundaries between these layers.
Build a logging policy before an alert rule
The Australian Signals Directorate’s Australian Cyber Security Centre, working with international partners, recommends an enterprise-approved logging policy, centralised log collection and correlation, protected log integrity and a detection strategy for relevant threats. ASD’s ACSC: best practices for event logging and threat detection
For a website, the policy should define:
- which systems log
- which event types matter
- time synchronisation
- format and identifiers
- retention period
- secure central storage
- access controls
- privacy and data minimisation
- alert ownership
- investigation access
- deletion and legal-hold rules
Logs stored only on the compromised server can be altered or destroyed. Centralisation and protected storage improve resilience and correlation.
Do not log secrets or unnecessary personal data
More logging is not automatically safer. Logs can become a sensitive data store.
OWASP’s Logging Cheat Sheet advises excluding or masking data such as access tokens, authentication passwords, sensitive personal information, database connection strings and encryption keys. It also recommends sanitising event data to prevent log injection. OWASP Cheat Sheet Series: logging
Decide what responders need to identify the event without reproducing the sensitive content involved.
The website events worth considering
The correct set depends on architecture and risk. The following categories provide a practical starting point.
1. Authentication and account events
Potentially useful events:
- repeated failed logins
- successful login after a failure burst
- login from an unusual location or network
- multi-factor authentication disabled
- administrator account created
- role or privilege changed
- password or email changed
- dormant privileged account used
- application credential created or revoked
- lockout or rate-limit threshold reached
OWASP’s authentication guidance recommends logging and reviewing authentication failures, password failures and account lockouts. OWASP Cheat Sheet Series: authentication
A failed login alone is common internet noise. A new administrator followed by plugin installation and outbound traffic is much more significant. Correlation creates value.
2. Application and code changes
Consider:
- WordPress core, plugin or theme installed
- component activated, deactivated or deleted
- unexpected file change
- executable file created in an upload directory
- production code changed outside the deployment process
- configuration changed
- scheduled task added
- security plugin or logging disabled
- integrity baseline changed without an approved release
Legitimate deployments create many of these events. Connect monitoring to the release calendar and deployment identity so authorised change can be distinguished from unexplained change.
WordPress states that keeping core, plugins and themes current is central to security and that security requires continuous planning, monitoring and maintenance. WordPress Advanced Administration Handbook: security
3. Web request and edge events
Consider:
- high-confidence WAF blocks
- repeated requests to sensitive paths
- automated credential attacks
- unusual request methods
- spikes in 4xx or 5xx responses
- unexpected bot or scraper activity
- denial-of-service conditions
- access to files that should not be public
- suspicious upload attempts
Do not alert a human for every blocked request. Aggregate commodity internet noise and escalate patterns that affect service, target a real asset or combine with other evidence.
4. Data and database events
Depending on the system:
- bulk export
- unusual query volume
- schema or administrator change
- new database user
- access outside normal application identity
- unexpected modification to payment, user or configuration records
- deletion or encryption pattern
Database logging must be designed with performance and privacy in mind. Prioritise privileged and high-impact events.
5. Ecommerce and business-logic events
Security can appear as abnormal business behaviour:
- payment failures or gateway changes
- unexpected refund or coupon activity
- prices changed across many products
- orders created without expected payment state
- shipping destination patterns
- mass account creation
- inventory altered unexpectedly
- checkout volume diverging from payment or order records
These alerts require commercial context. A promotion can look anomalous to a generic system, while a subtle misuse of a discount rule may look technically valid.
6. Integration and credential events
Consider:
- webhook failures or signature errors
- API authentication failures
- new API key or application password
- permission scope changed
- unexplained data export
- unusual request volume
- integration endpoint changed
- messages repeatedly retried or dead-lettered
WordPress Application Passwords are revocable credentials intended for programmatic access rather than interactive login. Monitoring creation and revocation can improve visibility into integration access. WordPress Advanced Administration Handbook: Application Passwords
7. Backup and recovery events
Alert on:
- backup failure
- missed schedule
- unexpected deletion
- retention gap
- restore test failure
- backup storage access change
- backup size changing materially
- replication or snapshot failure
A successful backup job is not proof the recovery point is clean or restorable. Test restoration and record the outcome.
8. Logging and monitoring health
Monitor the monitoring system:
- log source stops sending
- time drifts
- storage fills
- retention changes
- alert rule disabled
- collector authentication fails
- event volume changes unexpectedly
- responder notification fails
Silence can be an event.
Prioritise alerts by context and actionability
Use five dimensions.
Asset criticality
Is the event affecting checkout, administrator access, customer data, DNS or a low-risk public page?
Event confidence
How reliable is the detection? A confirmed file hash mismatch has different confidence from a generic traffic anomaly.
Potential impact
Could it involve data exposure, privileged access, fraud, prolonged outage or limited probing?
Corroboration
Does another source support the alert? Examples include an identity event plus a file change, or a WAF pattern plus a new user.
Actionability
Can the responder validate or contain it? An alert with no accessible evidence or authority creates delay.
Define severity levels with required response pathways. For example:
- Critical: credible active compromise, data risk or major service impact; immediate escalation and containment authority.
- High: suspicious privileged or code activity requiring urgent validation.
- Medium: meaningful weakness or pattern requiring scheduled investigation.
- Low: informational event retained for correlation or trend review.
Avoid severity based only on vendor labels. Apply the organisation’s asset and business context.
Every alert needs a runbook
An alert definition should contain:
- alert name
- purpose
- data source
- trigger condition
- exclusions and approved-change logic
- severity
- owner and backup owner
- first validation checks
- evidence to preserve
- permitted containment action
- escalation contacts
- communication rule
- closure criteria
- tuning history
Example:
Alert: New WordPress administrator outside approved process
First checks: Confirm account identity, creation time, creating user, source IP, related login and role events, current release or onboarding request.
Preserve: Relevant application, identity, WAF and server events; user record; active sessions.
Contain if unauthorised: Disable account and sessions according to authority; rotate affected credentials; assess related changes.
Escalate: Website support, internal IT/security and client incident owner based on evidence.
The runbook turns a notification into an operational response.
Define who responds and when
Business-hours monitoring
Can suit lower-risk sites where short detection delays are tolerable and an escalation contact exists.
On-call response
Alerts route to a designated responder outside business hours according to severity.
Security operations provider
A specialist service monitors and triages according to an agreement, potentially using a SIEM or managed detection platform.
Hosting-provider monitoring
May cover infrastructure and platform events but not all CMS, custom application, business-logic or customer-data events.
Website support monitoring
May cover application health, updates and defined website alerts. It should not be assumed to include 24/7 security operations, forensics or legal response unless expressly agreed.
The right model depends on risk, budget, operating hours and contractual obligations. Define handoff between the host, website team, internal IT, cybersecurity specialists and business owner.
Preserve evidence before destructive repair
When compromise is plausible:
- record alert and timeline
- preserve relevant logs
- capture volatile information where capability permits
- snapshot affected systems according to the response plan
- restrict unnecessary access
- record actions and decision-makers
- avoid overwriting the only evidence
Containment and restoration may need to happen quickly, but actions should be traceable. A routine website team may need to involve a specialist incident-response or forensic provider for serious events.
Test monitoring through controlled exercises
Do not wait for a real compromise to learn that the alert route fails.
With appropriate authorisation and safety controls, test events such as:
- create a test administrator through the approved mechanism
- fail authentication repeatedly from a controlled source
- change a monitored test file
- disable a non-production log source
- trigger a backup failure notification
- simulate an integration-signature failure
Ask:
- Was the event logged?
- Did it reach the central system?
- Did the rule fire?
- Did the right person receive it?
- Could they access the evidence?
- Did they follow the runbook?
- Was escalation timely?
- What noise or gaps appeared?
OWASP advises testing logging failure conditions and ensuring logging itself cannot be used to cause denial of service or application failure. OWASP Cheat Sheet Series: logging
Measure the monitoring programme
Useful measures include:
- percentage of critical systems sending expected logs
- time from event to alert
- time from alert to acknowledgement
- time from acknowledgement to triage decision
- false-positive rate by rule
- alerts without assigned owners
- runbooks tested
- missed or late backup jobs
- unresolved high-severity findings
- time to contain confirmed incidents
- repeat incident causes
Do not optimise only for fewer alerts. A low volume can mean good tuning or missing visibility. Review coverage and outcome together.
Common monitoring failures
Sending every event as an email
Responders become desensitised and important signals are missed.
Monitoring only uptime
A compromised site can remain available.
Monitoring only WordPress
DNS, hosting, identity, CDN, database, deployment and integrations can all be relevant.
Retaining logs only on the website server
An attacker or failure can remove the evidence.
Logging sensitive data
Monitoring creates a new risk if secrets and personal data are copied unnecessarily.
Buying a tool without response ownership
Detection without triage, authority and escalation is incomplete.
Treating a warranty as monitoring
A post-launch functional warranty does not provide an ongoing detection or incident-response service.
Emote’s role and service boundaries
Emote can support agreed website maintenance, application troubleshooting, monitoring configuration and coordination with a client’s hosting provider within the selected support arrangement. The exact alerts, coverage, response expectations and exclusions must be set out in current approved collateral and the relevant agreement.
Emote does not sell or resell hosting infrastructure. The client normally contracts directly with a suitable hosting provider. Infrastructure monitoring and response remain governed by that provider’s service, while application and business-level monitoring require separate definition.
Emote’s standard 30-day functional warranty covers agreed implementation functionality from production go-live. It is separate from ongoing security monitoring, software updates, incident response, forensic investigation, legal or privacy advice and enhancements. Higher-risk organisations may need a specialist security operations or incident-response provider working alongside the website, hosting and internal teams.
Frequently asked questions
What is website security monitoring?
It is the collection and analysis of relevant website, hosting, identity and application events to detect suspicious conditions and trigger a defined response.
Is uptime monitoring enough?
No. It detects availability problems but can miss compromised accounts, malicious code, data access and subtle business-logic abuse.
Which WordPress alerts matter most?
Priorities commonly include privileged account changes, unexplained code or plugin changes, logging disabled, suspicious authentication, backup failure and correlated indicators. The exact set depends on site risk.
Should every failed login create an alert?
Usually not to a human. Failed logins are common. Aggregate patterns and correlate them with account, location, privilege and subsequent success.
How long should logs be retained?
There is no universal period. Base it on threat detection, investigation, legal, contractual, privacy and storage requirements, with protected integrity and documented deletion.
Who should receive security alerts?
A named responder with the access, skill, availability and authority to triage them, plus an escalation path. A generic mailbox is not sufficient ownership.
Does a security plugin provide complete monitoring?
No single plugin sees every layer. Hosting, edge, identity, database, integrations and business systems may require other evidence.
Is security monitoring included in Emote’s warranty?
No. The standard 30-day functional warranty is distinct from ongoing monitoring and security response. Any monitoring or support coverage must be expressly agreed.
How Emote can help
Good website monitoring is deliberately selective. It collects the evidence required for the website’s risks, protects that evidence, detects meaningful conditions and gives an available responder a clear next step.
Emote’s website support and maintenance services can be scoped around agreed application checks, alert hand-offs and escalation paths.
If you are defining which website alerts matter and who should act on them, book a meeting with Emote to discuss the monitoring model.