Your IT Provider Says “The Problem Is Fixed.” How Can You Be Sure?
A security alert appears. Your IT provider investigates and later reports that everything is back to normal. But what was actually fixed? And how do you know the underlying risk has been addressed?
On Monday morning, an employee reports something strange happening on their computer.
The IT provider connects remotely.
They run a few checks, change a setting and restart a service.
A few hours later, the business owner receives an email:
"The issue has been resolved. Everything is back to normal."
Good news.
But there's an important question that often goes unanswered:
What exactly was wrong, and how do we know the security risk has been eliminated?
This isn't about questioning the competence of the IT provider.
It's about applying the same standard of accountability that any business would expect from other critical services.
Restoring a service is not the same as resolving a security incident
Imagine that a company's email service stops working.
The administrator restarts the affected component.
Employees can send and receive messages again.
From an operational perspective, the service is restored.
But what if the disruption was caused by unauthorized activity?
What if an attacker still has access?
What if the underlying vulnerability remains?
The fact that an application works again tells you that availability has been restored.
It doesn't necessarily tell you whether the security incident has been fully investigated.
The same distinction applies to a compromised account.
Resetting a password may restore the legitimate user's access.
But it doesn't automatically establish what the attacker did before losing access, whether other sessions remain active or whether additional systems were affected.
A system returning to normal operation is not, by itself, proof that a security incident is closed.
Business owners don't need fifty pages of technical logs
There's another problem.
Sometimes, a provider tries to demonstrate that an incident was handled correctly by sending a large technical export.
Windows events.
Firewall logs.
Vulnerability reports.
Authentication records.
For a security analyst, those records might be useful.
For a business owner, they often provide little reassurance because the business impact remains unclear.
A useful incident report should answer a few straightforward questions.
What happened?
Which business services were affected?
What did we do?
What did we verify afterward?
Is there anything left to address?
Technical evidence should support those answers, not replace them.
The NIST incident response guidance published in April 2025 emphasizes integrating incident response into cybersecurity risk management and improving the effectiveness of detection, response and recovery.
Source: NIST SP 800-61 Rev. 3 — Incident Response Recommendations
A practical example: an unusual email login
Let's say an organization receives an alert about suspicious access to an employee's mailbox.
The IT provider resets the user's password.
That may be an appropriate immediate containment measure.
But several questions remain.
Was the suspicious login successful?
Did the employee recognize the device?
Should existing sessions be revoked?
Was an unfamiliar MFA method registered?
Were forwarding rules created?
Were suspicious emails sent to customers or colleagues?
Did the account access confidential information?
Without checking these points, it is difficult to assess whether the problem was fully contained.
France's Cybermalveillance.gouv.fr recommends that victims of account compromise review account recovery information, forwarding rules and active sessions, as well as changing compromised passwords.
Source: Cybermalveillance.gouv.fr — Account Compromise Guidance
The forgotten actions after an intervention
Not every security issue can be completely resolved during the first intervention.
Sometimes, a temporary measure is applied.
An exposed service is restricted until a permanent configuration change can be scheduled.
An outdated system needs patching during an approved maintenance window.
A technical account must be replaced, but the business application needs testing first.
A backup exists, but restoration still needs to be verified.
These aren't necessarily reasons to keep the entire organization in emergency mode.
However, they do need to be tracked.
Each outstanding action should have an owner, a deadline and a clear status.
Otherwise, it is remarkably easy for everyone to assume that someone else is handling it.
And a temporary workaround can quietly become permanent.
Security is also a coordination problem
A cybersecurity incident rarely involves only one person.
The IT provider investigates.
The system administrator applies changes.
The business owner approves interruptions.
A department manager verifies that an application is working.
Sometimes, the legal team or data protection officer must also be involved.
These conversations quickly become fragmented.
A phone call here.
An email there.
A ticket that nobody has updated.
The provider believes they're waiting for the customer.
The customer believes the provider is working on the issue.
Meanwhile, the outstanding action remains unresolved.
This is why incident management needs more than technical skills.
It also needs clear responsibilities and a reliable way to track decisions.
Giving customers a clearer picture
For organizations using several managed security services, visibility becomes especially important.
They need to understand which services are in place, what has been reported, which incidents require attention and whether a response is expected from them.
That's one of the practical ideas behind Cyberhack Platform.
The customer workspace brings together information published by Cyberhack about managed services, reports, incident updates and relevant follow-up items.
When action is required, customers can review the information provided and respond or acknowledge updates as appropriate.
It isn't intended to eliminate conversations with security specialists.
Quite the opposite.
It gives those conversations a clearer starting point.
The business owner can focus on the decision that matters.
The IT manager can review the relevant technical issue.
And the security provider can maintain continuity across the follow-up process.
What if personal data was involved?
Some incidents create an additional responsibility.
Imagine that an attacker accesses a mailbox containing customer records, employee documents or other personal data.
Restoring the mailbox is not the end of the story.
The organization must assess whether a personal data breach occurred, what information may have been affected and what risks it creates for the people concerned.
Under the GDPR, organizations acting as data controllers must document personal data breaches.
If a breach is likely to result in a risk to individuals' rights and freedoms, the supervisory authority must be notified without undue delay and, where feasible, within 72 hours of becoming aware of it.
Where a high risk exists, the affected individuals may also need to be informed, subject to applicable exceptions.
Not every IT incident automatically triggers these notification requirements.
The obligation depends on the nature of the breach and the associated risk.
In France, the CNIL provides official guidance on how to assess and notify personal data breaches.
Source: CNIL — Reporting a Personal Data Breach
This is another reason why a simple "problem fixed" email may be insufficient.
The organization needs to know what happened, not just whether the system is working again.
Five questions to ask after a security incident
A business doesn't need to audit every technical decision made by its provider.
But it should expect a short, understandable incident summary.
That summary should answer five questions:
- What caused the incident? If the cause is still uncertain, which hypotheses remain under investigation?
- What was affected? Which accounts, devices, systems or business processes were involved?
- What actions were taken? What was contained, corrected, restored or disabled?
- How was the result verified? What evidence supports the conclusion that the immediate risk is controlled?
- What still needs to happen? Who owns the remaining actions, and when should they be completed?
These answers do not replace a full forensic investigation when one is necessary.
They provide a practical basis for understanding the situation and deciding what happens next.
Trust is built after an incident, too
No serious cybersecurity provider can promise that an organization will never experience an incident.
Threats change.
Software contains vulnerabilities.
People make mistakes.
Sometimes, attackers succeed despite reasonable safeguards.
What matters is how the organization responds.
Can the provider explain the problem clearly?
Can they distinguish confirmed findings from assumptions?
Can they demonstrate what was corrected?
Do they communicate unresolved risks?
Are follow-up actions actually completed?
These are meaningful indicators of the quality of a managed security service.
And they matter long after the immediate incident is over.
Conclusion
"The problem is fixed" is reassuring.
But it shouldn't be the end of the conversation.
Business owners don't need to understand every command that was executed or every event recorded in a security log.
They do need to understand what was discovered, what was corrected, how the result was verified and whether any risks remain.
A properly managed incident is not simply one after which everything starts working again.
It's one where the impact has been assessed, the response documented and the remaining risks clearly understood.
That level of transparency is what builds lasting trust between a business and the people responsible for protecting it.
