Website security monitoring.
Know what needs a response.
A website alert is useful when someone can explain what it means and what happens next. WebXd helps you define the security signals to watch, the evidence to review, and the people authorized to respond when your website needs attention.
An unfamiliar administrator is a question worth opening.
Imagine a new administrator account appearing in your CMS without a matching change request. The public pages still load, but that observation says little about who created the account or what access it has. Start a review with the account event and its surrounding evidence.
The record should connect the event time, available login history, and recent approved changes. Ask the site owner whether the account belongs to a planned integration or a new colleague. Preserve the relevant records before making changes that could erase useful context.
- Observed
- A new account has administrator permissions.
- Missing
- No matching approval is attached to the record.
- Next question
- Who created it, and was that action authorized?
Let the evidence change the status.
An alert identifies something to examine; it does not establish a breach by itself. Triage checks the signal against normal activity and your incident criteria. NIST's incident response guidance supports analyzing events before declaring an incident, while recognizing that incomplete evidence may still require escalation.
Explained activity
The owner confirms an approved account and the records support that explanation. Document why the alert was closed, then adjust the rule if it repeatedly flags expected work. Keep the event available under the agreed retention policy.
Unresolved suspicion
The account has no clear owner, or the available logs leave important questions unanswered. Record what remains uncertain and escalate according to the agreed risk criteria. Avoid treating a missing record as proof that the activity was harmless.
Confirmed incident
Evidence supports unauthorized access or another condition that meets your incident criteria. The responsible lead moves the work into the response plan, with an affected scope and authorized actions. Specialist investigation may be needed to establish the full extent.
Name what each check can actually see.
A monitoring plan starts with the systems you own and the access available to inspect them. Public checks, hosting records, and application events answer different questions. We map these sources before choosing tools so the report can describe its coverage and its blind spots.
| Evidence source | Useful observation | Important limit |
|---|---|---|
| Public website checks | Availability, certificate status, visible redirects or changed content | Cannot inspect private files or establish who changed them |
| Hosting and CMS records | Account changes, login events, file changes where supported | Depends on permissions, log quality, and retention |
| Dependency advisories | Known issues affecting an installed component and version | Do not establish that exploitation occurred |
A clean remote malware scan cannot establish that server files are clean. Likewise, a successful uptime check only shows that the tested endpoint responded at that moment. If an application does not record the event we need, improving its logging becomes a separate engineering task.
Review the routes that can change your site.
The CMS is only one part of the access picture. Hosting, domain management, deployment tools, and connected services can also affect the website. Review privileged accounts with their owners, remove obsolete access, and consider multifactor authentication with a usable recovery procedure.
Software inventory makes an advisory actionable: identify the installed version, its exposure, and the owner who can approve remediation. Vendor guidance and CISA's Known Exploited Vulnerabilities catalog can inform priorities. A scheduled update belongs in maintenance; evidence of possible exploitation needs a security review.
- A named owner for each privileged account
- Only the permissions needed for the person's task
- Current components and known support status
- An agreed route from an advisory to a change decision
Write the action authority before an urgent decision.
Disabling an account or restricting a site can interrupt legitimate work. Agree which actions are already authorized, which need approval, and who acts if the primary contact is unavailable. WebXd's proposed role, your host's responsibilities, and any specialist response support should be explicit.
For the fictional administrator alert, preserving the event and contacting the owner may be routine review actions. Suspending access, rotating credentials, or isolating part of the site requires the authority set out in the plan. Record the reason and result of each action.
| Decision | Agreement needed |
|---|---|
| Restrict an account | Who can authorize it; how legitimate access will be restored |
| Change a firewall rule | Who approves it; which visitor tasks need checking |
| Take a service offline | Who decides; how the host and site owner are reached |
| Escalate investigation | Who engages specialist help; what evidence may be shared |
Recovery needs more than a page that loads.
If response work includes a restore, check the restoration source before using it and verify the recovered site afterward. A backup can contain the same unwanted change. Address the identified entry point and review affected access as part of the agreed recovery work.
Check the important visitor tasks as well as the evidence that triggered the response. Keep a record of what was restored, which tests passed, and which questions remain open. Agree who accepts the return to service and whether additional observation or investigation is required.
- Restoration source and integrity checks
- Affected access and entry point reviewed
- Important site tasks tested
- Remaining uncertainty assigned to an owner
Report the facts, including what is still unknown.
A useful report connects the signal to the evidence reviewed, its classification, and the next decision. Include failed checks and missing data so a quiet dashboard cannot hide a gap in observation. Record the review window rather than implying coverage outside the agreed arrangement.
Security records can contain sensitive information. Agree who may access them, how they are shared, and how long they are retained. OWASP's logging guidance advises excluding or protecting passwords, tokens, and sensitive data. Collect the context needed for review without turning the report into another exposure.
Keep routine site care and incident work connected through clear handoffs. Our website maintenance service covers planned upkeep, while this scope addresses security signals and response coordination. CMS support and backend development can help resolve platform issues or add the application evidence a review needs.
Define coverage before relying on it.
Does monitoring include round-the-clock human response?
Automated checks and human review are separate parts of a service. Review hours, alert routing, escalation contacts, and any response commitments must be agreed in your proposal. A monitoring tool running continuously does not establish that someone is available to respond at every hour.
Can you help if we suspect an incident now?
Contact WebXd with a brief description of the signal and your existing response contacts. We can discuss the available scope and coordination needs. An active investigation, malware cleanup, or specialist forensic work needs its own assessment; this page does not promise emergency availability.
Is vulnerability scanning the same as penetration testing?
No. Scanning identifies potential issues within the tool's coverage, while penetration testing examines an explicitly authorized set of systems and scenarios. Any testing scope, access, and rules need agreement. Neither a scan nor a test guarantees that every weakness has been found.
Does a security report certify compliance?
The report documents observations and agreed actions within its scope. It does not certify legal compliance or determine notification duties. Your designated security lead and advisers should handle those decisions, using the technical record and any specialist findings required by your organization.