IT Security ServicesAssess · Harden · Monitor · Respond

Vulnerability scan, penetration test or security review: what is the difference?

A vulnerability scan is a tool comparing what it can see against a list of known weaknesses: old software versions, weak TLS settings, missing headers. It is fast, cheap and worth running continuously, but it cannot tell whether a customer can open someone else's invoice by changing a number in the address bar.

A penetration test is a person trying to break in within an agreed scope, usually against one application or network. A security review, as Miracuves runs it, includes that manual testing and adds what surrounds it: who holds access to production, what answers from the internet, how data and backups are handled, and whether anything would raise an alert. It ends with a fix for each finding and a retest, not only a list of problems.

When should a company commission a security review?

Most reviews are triggered by a change rather than a calendar date. The common ones are below. Between them, automated scanning and dependency alerts cover routine ground far more cheaply than a person can.

• Before launching a product that stores customer or payment data
• When an enterprise customer sends a security questionnaire
• After inheriting a codebase, an agency's work or an acquired company
• After a developer or contractor with production access leaves
• After a cloud migration or a new payment or identity provider

How is the risk of a finding decided?

Severity scores such as CVSS are a starting input, not the answer. A flaw rated critical in a component that nothing can reach matters less than a medium-rated weakness on a login page that faces the internet. Each finding is weighed on four things: where an attacker would have to start, what access they would need, what data or action it exposes, and whether it can be chained with other findings into a longer path.

That is why a forgotten staging admin panel or an API key with more permission than anyone intended so often tops the report. Each finding states its reasoning, so your team can challenge the ranking rather than take it on trust.

What should we prepare before testing starts?

The written scope lists what is needed, but preparing a few things early shortens the engagement and keeps testing away from anything fragile.

• A list of domains, applications and cloud accounts you believe are in use
• Test accounts at each user role, ideally on a staging copy of production
• A named contact who can be reached during the testing window
• Anything that must not be touched, such as a payment flow or a live database
• Recent backups, confirmed before any testing against production

Does a security review help with ISO 27001, SOC 2 or a buyer's questionnaire?

It helps you prepare, but it is not a certificate. ISO 27001 certification is issued by an accredited certification body, and a SOC 2 report comes from an independent auditing firm. Miracuves does not hold or issue either. When Miracuves applies fixes, we build to the controls those frameworks require, such as access reviews, logging and tested backups.

A review run before the audit finds and closes the gaps an auditor would otherwise record. For an enterprise questionnaire, the findings report and the written retest are evidence of what was tested and what was fixed, which is often what the buyer's security team wants to see.

What happens after the report is delivered?

Your team works through the findings in the order the report gives, using the fix supplied for each one. If you prefer, Miracuves applies the fixes alongside your engineers as a separate scope agreed at the start. Anything critical found during testing will already have been raised the same day rather than held for the report.

Once the fixes are in, the retest checks each finding again and records in writing which items are closed and which remain open, with the reason. That record, not the original report, is what shows the work is finished. Most teams then repeat a review annually or after the next significant architectural change.