The article
You probably have more logs than you think. Your cloud keeps them, your email service keeps them, and so do your firewall and your application. Two questions decide whether they protect you: would anyone notice the one line that matters, and how far back could you look when they do? Cyber security monitoring consulting answers both before you buy a tool: what to watch, which logs to collect, which alerts deserve a person and whether to run it yourselves or have it managed.
I have been building software for 18 years, and since 2017 my team of 70+ specialists has delivered 150+ projects. Below is how I would design monitoring for a company of your size: the decisions, a worksheet you can fill in this week, three questions every alert has to pass and what the work costs. Watching the alerts afterwards can stay with your team or move to the security side of our company.
What cyber security monitoring consulting decides
| Decision | What it means |
|---|---|
| What to watch | The systems and accounts worth watching, starting where your data and money are |
| Which logs, and for how long | The records to collect, where they are kept and how far back they go |
| Which alerts deserve a person | Rules tuned to cut the noise, so the real alert is not lost among the rest |
| Who answers | A named person and a deputy for every alert, day and night |
| Who runs it | Your team, a managed service or a mix |
| Price | The first call and the rough estimate are free; the work is estimated before it starts |
Start with the questions, not the tool
The right setup depends on your size and your risk, not on a catalog. A small company may need the logs its cloud already keeps and a few good alerts; a larger one may need a SIEM, a system that gathers the logs from everywhere in one place, and a team behind it. Buying the tool first gives you a dashboard nobody reads.
Sales pages tend to skip this part. In October 2026 I read the four consulting pages Google shows first for this search: two promise monitoring around the clock, yet none uses the word "alert", none mentions a SIEM and none says how long logs are kept. Four pages are a small sample, but those three things are the design.
How far back can you look
An intrusion is not always found the day it starts, so the first question after an alert is how far back the records go. Check your defaults before you need them. In AWS, for example, the default event history keeps 90 days of management events in each region; a longer record needs a trail or an event data store that someone set up in advance. Your rules or contracts may set their own minimum, so ask your compliance advisor which applies to you.
Two more things decide whether old logs help. They must be kept where an attacker with admin rights cannot delete them, which is part of cloud security, and the clocks of your systems must agree, so events from different places line up in one timeline.
The monitoring worksheet
This is the worksheet I would fill in with any client before choosing a tool. Every row needs all four columns: an empty last column means nobody will act.
| What to watch | Where the record lives | Alert a person when | Who answers |
|---|---|---|---|
| Sign-ins to email and admin tools | The identity provider's sign-in log | A sign-in from an odd place or hour, followed by a password or two-factor change | IT on call |
| Mailboxes | The email service's audit log | A new rule forwards mail outside the company | IT, then the mailbox owner |
| Cloud accounts | The cloud's audit trail | Logging switched off, a new admin, new access keys | DevOps |
| Servers | System and security logs | A new admin account, the security agent stopped | DevOps |
| Laptops | The endpoint protection console | Malware found, or protection switched off | IT |
| Your application | Application and audit logs | A burst of failed logins, an admin exporting large amounts of data | The app team |
| Backups | Backup job reports | A failed or skipped backup | DevOps |
| The website | An uptime check from outside | The site stops answering | Whoever is on call |
Three questions before an alert becomes a rule
Every alert rule should pass three questions:
- Would someone act on it at 3 a.m.? If not, it belongs in a weekly report, not in an alert.
- Who exactly acts, and what is the first step? Lock the account, isolate the laptop, call the vendor.
- What happens if they do nothing? If the honest answer is "nothing much", the rule is noise.
When most alerts need no action, people stop reading them, and the real one arrives unread. Rules that pass these questions keep the count low enough that every alert still gets a look.
Your team, a managed service or a mix
- Your team fits when the systems are few and someone can be on call: the cloud's own logs, a handful of alerts, a named responder.
- A managed service fits when nobody on your team has time to watch: cyber security monitoring services put people behind your alerts, and we run them too.
- A mix keeps your IT team in charge of the systems while a provider watches, responds and advises beside it, as in co-managed managed cybersecurity services.
Whichever you choose, the design comes first, and the logs stay in accounts in your company's name.
Our work
- Uptime we watch ourselves. For the websites we host, our team watches uptime while support runs and tells the owner what happened and where; more in website maintenance. The owner hears it from us, not from a client.
- A page for the bad minute. When the server behind our own site stops answering, visitors get our page instead of a bare 502 error, rebuilt from the live content with every release.
- Records inside the application. On RxPhoto, the photo platform for clinics where we worked on the backend, the web front end and the API behind the mobile app, an audit log lets administrators follow every user action. Records like these are worth watching: an admin opening hundreds of records at 3 a.m. is a signal no firewall sees. When an application lacks such records, our developers add them in the code.
- Servers watched next to the code. In managed cloud services, our DevOps engineers keep servers patched, watched, backed up and secured beside our developers, so a fault gets fixed in the code, not only on the server.
What the price depends on
- how many systems, accounts and log sources are in scope;
- how long the logs must be kept, and where;
- how many alert rules need writing and tuning;
- whether the work includes choosing and setting up the tools;
- who will run the monitoring: your team, us or both.
The first call and the rough estimate are free; the full estimate comes before any work starts.
What stays yours
The design itself: the list of sources, how long each is kept, every alert rule with its owner and the on-call order. The logs and the rules should live in accounts in your company's name, so a change of provider does not take your history with it.
Next to this service
Monitoring design is one part of cybersecurity consulting. Who does what after an alert belongs in your incident response plan; logs that also serve an auditor are part of compliance consulting.
Tell us what you watch today. We reply with what we would change first and a rough estimate, free; on weekdays from 9 am to 6 pm Miami time, within 30 minutes.
