On this page
What security monitoring does
Even a well-hardened system can be compromised: a password leaks, a new vulnerability is published, a staff laptop is infected. The difference between a minor incident and a serious one is often how quickly it is noticed. Security monitoring watches your systems for signs of trouble and tells the right person when something unusual happens.
Monitoring that produces hundreds of alerts a day is almost as bad as none, because people stop reading them. Our service focuses on a small number of meaningful signals, tuned to your systems, with logs kept long enough to investigate properly afterwards.
Good monitoring also answers questions after the fact. When something odd happens — a page changes unexpectedly, an order looks suspicious, a customer reports a strange email — reliable logs let you establish what happened, when, and through which account. Without them, an investigation becomes guesswork, and it is much harder to be confident that a problem has really been contained.
Who needs it
Monitoring matters most where a compromise would go unnoticed for too long. That includes an online store processing orders overnight, a clinic’s patient booking system, a real estate portal holding lead and owner details, a SaaS product with customer data, and a manufacturer’s ERP-connected portal used by dealers.
- You would currently learn about a breach from a customer, a search engine warning or your hosting provider.
- Logs are deleted after a few days, or not collected at all.
- Alerts go to a shared inbox that nobody checks.
- You can’t say who logged in to your servers last week.
What we watch for
| Signal | Why it matters |
|---|---|
| Unexpected logins | Logins at unusual times, from new locations or to accounts that are normally unused can indicate stolen credentials. |
| Privilege changes | New admin users, new sudo rights or new SSH keys are common steps after an intrusion. |
| File integrity | Changes to core application files, configuration or web directories outside a deployment can mean injected code. |
| Unusual traffic | Spikes in failed logins, requests to unusual paths or sudden outbound connections can signal an attack or a compromised service. |
| Service and certificate health | Stopped security services, disabled firewalls or expiring certificates weaken your defences quietly. |
What’s included
- Agreed monitoring rules for each system, based on how it is normally used.
- Log collection and retention for authentication, web server and system logs, kept for an agreed period.
- File integrity monitoring on the directories that matter.
- Alert routing to named people through channels they actually use, such as email or a messaging app, with escalation if nobody responds.
- A response runbook describing the first steps to take for each type of alert.
- Periodic tuning, so false alarms are reduced rather than ignored.
How we deliver it
- Confirm scope and authorisation for the systems to be monitored, and agree what data may be collected and where it is stored.
- Learn normal behaviour — who logs in, when deployments happen, what traffic looks like.
- Configure collection and rules, starting with high-value signals.
- Run a tuning period, adjusting thresholds until alerts are rare and meaningful.
- Agree routing and response, including who is notified out of hours if that is needed.
- Review regularly and update rules as your systems change.
What affects timeline and cost
- The number and type of systems — servers, websites, cloud accounts.
- How long logs need to be retained and how much storage that requires.
- Whether alerts need out-of-hours response, and who provides it.
- Whether monitoring tools already exist and need tuning, or are being introduced from scratch.
Common mistakes
- Turning on every alert a tool offers, then muting them all within a week.
- Storing logs only on the server being monitored, where an attacker can delete them.
- Monitoring uptime but not security events — the site can be up and compromised.
- Having alerts but no agreed plan for what to do when one fires.
Frequently asked questions
Is this a 24/7 security operations centre?
No. We set up and tune monitoring and alerting for your systems. Out-of-hours response can be arranged where your business needs it, and we’re clear about what cover is and isn’t included.
How long should logs be kept?
Long enough to investigate an incident that is discovered late. The right period depends on your systems and any obligations you have; we agree it with you and size storage accordingly.
Will monitoring slow our servers down?
Well-configured monitoring has a small footprint. We collect what’s useful rather than everything, and send logs off the server so they’re safe and don’t fill the disk.
Can you monitor systems hosted with different providers?
Yes. Logs and alerts from servers, websites and cloud accounts at different providers can be collected in one place, so you have a single view instead of several dashboards.
What happens when an alert fires?
The named person receives it with enough context to act, and the runbook describes the first steps. If we provide support, we can investigate with you.
Talk to us about security monitoring
Alerts on suspicious logins, unexpected file changes and unusual traffic.