Role
IT security
How quickly do you find out about a critical vulnerability in a system you run? That number decides whether the window between disclosure and patch is a risk or just a task.
Intro call
Four questions we would start with
How quickly do you find out about a new vulnerability in a component you use?
If it is from a newsletter once a week, the response window is a week whatever the severity.
How many times a day does an alert turn out to be false?
If the team has stopped reading the alerts, the monitoring works on paper rather than in fact.
When is the decision made to switch off a vulnerable service?
If the answer is never, because the business will not allow it, it is worth knowing that before an incident rather than during one.
What do you put off first when there are more tickets than people?
Usually: medium vulnerabilities and reviews - which is where the incidents six months from now come from.
We take over the gathering and the prioritising, you keep the judgement and the decisions
Gathering information about vulnerabilities, screening the noise out of alerts, collecting context during an incident and keeping the documentation can be taken off the desk. Judging the threat and deciding how to respond stay with the specialist.
- A vulnerability is tied to your environment. - Not every critical vulnerability concerns you, and the priority depends on where the component is used and whether it is exposed.
- An alert arrives with context. - What else was happening in that window, which events are related, whether the pattern has occurred before.
- An incident has its chronology recorded. - During, not after - because reconstructing it a week later is always worse and always more expensive.
Scope
What can be taken off IT security
Nineteen example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your attack surface.
Vulnerabilities and their priority
- Tying a published vulnerability to the components you use
- Pointing out the systems where the component is exposed
- A proposed priority by exposure and criticality (decision: the specialist)
- The status of remediation by system
- A signal when a critical vulnerability has been open longer than agreed
Monitoring and alerts
- An alert with the context of events from the same window
- Grouping alerts that share a cause
- Pointing out the rules with the highest share of false hits, excluding high-severity rules
- A signal when a system has no monitoring coverage
Incidents
- Assembling the data needed to assess an event
- The incident chronology recorded as it happens
- Notifying the agreed people according to severity (decision: the specialist)
- A draft post-incident report (content: the specialist)
Employee awareness
- A schedule of training and phishing simulations
- Results summarised by department, without naming individuals
- Refresher material for the areas with the lowest results
Compliance and audits
- A summary of the evidence required by the standard
- The status of corrective actions after an audit
- A register of security exceptions with a review date
A day's work
Today
- You learn about vulnerabilities from lists and newsletters
- Working out whether one concerns you takes hours per system
- Alerts arrive in numbers nobody reviews in full
- During an incident you start by collecting logs from several places
- You reconstruct the incident chronology after the fact
- You collect evidence for an audit over two weeks
With AI assistance
- A vulnerability is tied to the components you actually have
- You can see where the component is exposed, and the priority has a basis
- Alerts are grouped and the rules generating noise are pointed out
- An incident starts with the context already gathered
- The chronology is recorded as the event unfolds
- Evidence for the audit is gathered as you go
- Time to fix a critical vulnerability
a shorter window between disclosure and patch
the vulnerability is tied to the environment straight away
- Noise in security alerts
the team reads the alerts, because there are fewer of them
the rules generating noise are pointed out
- Time to respond to an incident
less time on gathering, more on decisions
the context sits with the report
- Resilience to phishing
you can see which areas need a refresher
test results are summarised by department
We start by tying vulnerabilities to your environment, because that shortens response time fastest.
- Step 1
Vulnerabilities against the components you use
What you actually have, where it is exposed, what priority it carries for you.
- Step 2
Order in the alerts
Grouping, context and pointing out the rules that generate noise.
- Step 3
Incident handling
Context with the report and the chronology recorded as it happens.
- Step 4
Compliance and awareness
Audit evidence and summaries from phishing simulations. Last, because it rests on vulnerabilities and alerts being in order.
Common questions
Questions that come up at the first meeting
How is this different from systems maintenance and access management?
The administrator keeps the systems running, access management decides who sees what. Here the subject is vulnerabilities, threats and incidents. The areas meet at updates and at excessive permissions, but the daily questions are completely different.
Does this mean fewer people in security?
Security teams are almost everywhere too small for the number of alerts, and that is why alerts stop being read. Taking the noise away does not shrink the team, it restores its ability to notice the unusual. In a saturated queue a targeted attack is lost all the more surely, and that is what this whole conversation is about.
Does this fall under the AI Act?
IT security is not a high-risk use. The line runs at data about employee behaviour: the results of phishing simulations and the analysis of events can point to particular people, so we keep the summaries by department and system rather than by name - otherwise it would be employee monitoring.
Still have a question that is not here? Book a call
Next step
How many of your critical vulnerabilities have been open for more than a month?
We will show you what a security team's work looks like when a vulnerability is tied to the environment and an incident starts with context.