Services · Implementation
Vulnerability and patch management: we re-scan to confirm it
Scanning, prioritization by current exploitability and patch deployment, with an independent re-scan before any ticket is closed: closed is not fixed.
Why this matters
A closed ticket isn't the same as a closed vulnerability. A patch can fail silently, apply to the wrong version, or get rolled back by a later change, and a ticketing system will still show "resolved" unless someone actually re-scans to confirm it.
Patches that silently fail
A patch deployment can report success in the tool while the underlying vulnerability remains exploitable.
Tickets closed on faith
A ticket marked resolved by the person who applied the fix isn't the same as independent verification.
Regressions after the fact
A later system rebuild, rollback or reimage can quietly reintroduce a vulnerability that was already fixed.
Scan blind spots
An asset added outside your normal provisioning process may never get included in the scan scope.
What sets this apart
We re-scan to confirm it, not just close the ticket. We don't just deploy patches and close tickets: we go back and re-scan to confirm each vulnerability is actually closed, not just marked resolved, and hand you a specific action for anything that comes back open.
- Patch verification: confirmed by an independent re-scan, not by the closed ticket alone.
- Reopened findings: tracked when a fixed vulnerability resurfaces after a rebuild or rollback.
- Scan scope: reviewed for assets that may have drifted outside normal coverage.
- Prioritization: re-checked against current exploitability, not just the original severity score.
Sample validation findings
Illustrative examples; they do not describe a specific client.
- High: a critical vulnerability marked "patched" three weeks ago is still exploitable on re-scan. Action: reapply the patch, confirm the correct version was targeted, and re-scan before closing.
- High: four servers reverted to a vulnerable state after a snapshot rollback last month. Action: re-patch the affected servers and add a post-rollback verification step to the process.
- Medium: five assets provisioned outside the standard process are missing from the scan scope. Action: add the assets to the scan scope and confirm asset inventory reconciliation runs regularly.
- Low: a medium-severity finding from two months ago has no documented remediation owner. Action: assign an owner and a target date, then confirm closure with a re-scan.
What you get
Scanning that covers the whole estate
Vulnerability scanning across your infrastructure, applications and cloud environments, with the scope reviewed to include assets provisioned outside the standard process.
Risk-based prioritization
Vulnerabilities prioritized by current exploitability and your business context, with an owner and a target date for every finding.
Patches staged and deployed
Patches staged and tested before broad deployment, scheduled around your maintenance windows.
Closure confirmed by re-scan
A ticket closes only once the fix is confirmed by an independent re-scan; findings that come back open are tracked until they are actually closed.
A report with one action per reopened finding
Every vulnerability still exploitable, every asset outside scope and every finding without an owner gets a specific action.
Our approach
- Scanning and discovery. Automated scanning across your entire environment (networks, applications, cloud assets) to identify vulnerabilities, misconfigurations and missing patches, with the scope reconciled against the asset inventory.
- Risk-based prioritization. Correlation of vulnerabilities with current exploitability and your business context, to prioritize remediation based on actual risk.
- Coordinated remediation. A deployment plan for patches and mitigations, staged and tested, with automation where possible and scheduling around your maintenance windows.
- Re-scan and report. Independent re-scan of every fix before closure, tracking of reopened findings, then hand-off of the report with a specific action for anything that comes back open.
Scoped to your environment and risk tolerance
Continuous scanning, risk-based prioritization, automated patch deployment, post-remediation re-scan: scan frequency is typically continuous or weekly for critical assets, with a full sweep on a regular cadence.
After the engagement
An implementation engagement is a defined project. Ongoing scan, triage and remediation tracking with SLA targets is available through Managed Security Operations, as a closed loop. Flaw remediation is also one of the 13 Level 1 controls of CPCSC (03.14.01) and a domain of CAN/DGSI 104; this engagement delivers the control and its evidence. The endpoints and servers being scanned belong to the endpoint and server protection service for their EDR and hardening.
The vulnerabilities you know about are the ones you can fix.
Let's talk about your current scanning and patching process.
Frequently asked questions
- How often do you scan?
- Scan frequency is scoped to your environment and risk tolerance: typically continuous or weekly for critical assets, with a full sweep on a regular cadence. The scan scope is also reviewed for assets provisioned outside the standard process, which often drift outside normal coverage without anyone noticing.
- Will patching cause outages?
- We stage and test patches before broad deployment, and schedule production changes around your maintenance windows. After a rollback, rebuild or reimage, a verification step is added to the process so that a vulnerability that was already fixed is not quietly reintroduced.
- Why re-scan if the ticket is closed?
- Because a patch can fail silently, apply to the wrong version or get rolled back by a later change, and a ticketing system will still show "resolved". A ticket marked resolved by the person who applied the fix isn't the same as independent verification; with us, a ticket closes only once the fix is confirmed by a re-scan.
- How do you prioritize vulnerabilities?
- By current exploitability and your business context, not just the original severity score. Prioritization is re-checked as the threat landscape evolves, every finding gets a remediation owner and a target date, and findings that reopen after a rebuild or rollback are tracked separately until their closure is confirmed.
- Can this become an ongoing managed service?
- Yes. The implementation engagement sets up the process (scan, prioritize, deploy, re-scan) and ends with a report. Ongoing scan, triage and remediation tracking with SLA targets is then available through our Managed Security Operations service, a closed-loop process where a finding is closed only after a re-scan.
Related pages
Services · Implementation
Endpoint and server protection: we test the response
EDR and hardening baselines deployed on SentinelOne, Microsoft Defender or your platform, then validated per endpoint: tamper protection, policies, isolation.
Services · Implementation
Network security: we review every rule, not just new ones
Firewalls, segmentation and remote access (VPN, ZTNA) deployed on the vendor you already have, then the full rule set reviewed for least privilege and tested.
Services · Implementation
Cloud security: configuration validated, not just guardrails
CSPM, guardrails and configuration baselines deployed on Azure, AWS or Google Cloud, then the real configuration validated against a hardening benchmark.
Services · Managed services
Managed security operations: continuous validation
Controls that were implemented correctly still drift. We keep them effective with a periodic check framework, weekly to annual, documented at every cadence.
Services · Compliance
CPCSC certification support (Levels 1, 2 and 3)
CPCSC is becoming a contractual requirement for defence suppliers. Sentrix structures your process at Levels 1, 2 and 3, from gap analysis to evidence.
Let's talk about your compliance program.
Last updated: 2026-09-17