Hardening vs Patching for an Online Casino: Which One Your Auditor Means

Q: What is the difference between hardening and patching?

Patching installs a vendor fix for a known flaw in software. Hardening sets a system to a deliberately secure configuration: removing services and accounts you do not need, changing defaults and restricting access. A fully patched server can still be badly configured, and a hardened one can still be missing a patch.

Q: Does patching count as hardening for an audit?

No. Auditors treat them as separate controls with separate evidence. In PCI DSS, secure configuration sits in Requirement 2 and patching in Requirement 6. In ISO/IEC 27001:2022, configuration management is Annex A 8.9 and technical vulnerability management is A.8.8.

Q: Which does PCI DSS 4.0.1 put a deadline on, hardening or patching?

Patching. Requirement 6.3.3 sets a one-month installation window for patches ranked critical under the process in 6.3.1. Requirement 2 asks for documented configuration standards that are applied and kept current, not for a deadline. Read the current standard text for the exact wording that applies to you.

Q: Can a vulnerability scan prove a system is hardened?

Only in part. A scan finds known vulnerabilities and some misconfigurations, but it does not show that a documented baseline was applied or that deviations were approved. Hardening evidence is the baseline, a comparison against it, and an exceptions record.

Q: What should a casino show an auditor who asks for both?

Two sets of evidence. For hardening: the named baseline per system type, the date it was last verified, and the register of approved exceptions. For patching: the vulnerability inventory, the risk ranking, the patch dates against your own deadlines, and anything deferred with sign-off.

The short answer

Hardening and patching are different controls with different evidence, and an auditor who asks for one is not accepting the other. Patching installs a vendor fix for a known flaw. Hardening fixes the configuration: services switched off, defaults changed, access narrowed, all against a written baseline. PCI DSS puts them in separate requirements, and ISO/IEC 27001:2022 puts them in separate Annex A controls. An online casino that answers a hardening question with a patch report fails the question even if every patch is current.

Who this is for

This is for the CISO, head of infrastructure or compliance owner at a licensed online casino who has received an audit request or questionnaire line that says "hardening" or "patch management" and is unsure which evidence to send. It is about telling the two apart. For the order in which to harden a casino estate, see cloud and server hardening for an online casino; for what to ask when buying hardening work, see server hardening services: scan, script, or engagement.

How the two differ

	Patching	Hardening
What it changes	Software version, to include a vendor fix	Configuration: services, accounts, defaults, permissions
What triggers it	A disclosed flaw	A written baseline, before any flaw is known
Where it goes wrong	A patch is missed or deferred	A setting was never changed, or changed back
Typical evidence	Inventory, risk ranking, patch dates, deferral approvals	Named baseline, verification date, exceptions register
Decays by	New disclosures arriving	Drift: new accounts, emergency changes, new hosts

The practical consequence is that each control can fail while the other passes. A casino database server on the latest release with a default administrative account and a management port open to the internet is fully patched and badly hardened. An old but tightly configured internal host is the reverse.

Where the standards draw the line

Standards are explicit about the split, which is useful when you must route an auditor's question.

Standard	Hardening sits in	Patching sits in
PCI DSS 4.0.1	Requirement 2: apply secure configurations to all system components	Requirement 6: develop and maintain secure systems and software, including 6.3.3 on installing patches
ISO/IEC 27001:2022	Annex A 8.9, configuration management: configurations are established, documented, implemented, monitored and reviewed	Annex A 8.8, management of technical vulnerabilities: a continuing process to find, assess and respond

Two details are worth knowing before an audit. PCI DSS Requirement 2 asks for documented configuration standards for each type of in-scope system, consistent with industry-accepted hardening guidance, and keeps them current; it sets no patch deadline. Requirement 6.3.3 is where the clock is: patches ranked critical under the risk-ranking process in 6.3.1 are installed within one month of release, with other patches on a timeframe the entity defines. Wording on which severities the one-month window covers has differed between versions of the standard, so read the current text with your assessor rather than a summary, including this one.

ISO/IEC 27001 sets no day counts at all. Any "critical in 14 days" figure you see is a policy choice by an organisation or a vendor, not a clause. If you have written such a deadline into your own policy, the auditor will test against your policy.

What to hold for each

For a hardening request, assemble:

The baseline you apply, named by system type: operating system image, database, hypervisor, container host, cloud account. A baseline you can name by version is stronger than "industry best practice".
The date each baseline was last compared against live systems, and the result.
An exceptions register: each deviation, who approved it, why, and when it is reviewed.
The change record showing that an emergency change did not silently undo a setting.

For a patching request, assemble:

The inventory the patching applies to. Patching an incomplete list is the most common gap.
The risk ranking you used, and how it maps to your own deadlines.
Patch dates against those deadlines, and for anything late, a signed deferral with the compensating control.
How you learn about new disclosures for the products you run.

If you hold only the second set, you have evidence for patching and nothing for hardening. The reverse is as common in teams that built a baseline once and never connected it to vulnerability management.

Why casinos mix them up

A casino estate changes at the speed of promotions and game launches. New hosts appear for a tournament or a provider integration and are patched by the standard pipeline because the pipeline is automatic. Configuration is not automatic: it depends on someone applying the baseline to the new host. The patch report looks clean and the hardening state is unknown. That gap is the subject of any later drift check, and a vulnerability scan only partly closes it, because a scan finds known weaknesses and some misconfigurations but does not show that a documented baseline was applied.

The same confusion appears in the other direction. A hardening effort is sometimes approved as "the patching project", gets scoped to software updates, and never reaches default accounts or exposed management interfaces. Say in writing which one a piece of work covers.

Limitations

This is a routing guide, not legal or audit advice, and it quotes no market prices, durations or AnySec-original figures. Standards are revised; confirm the clause wording against the current published text and your assessor's interpretation. It does not cover jurisdiction-specific gambling-licence technical standards, which may impose their own requirements.

What to do next

Take the audit line you are stuck on and decide which half of the table it belongs to, then send that evidence only. If you cannot produce the hardening half, request a baseline review for your casino estate and tell us the system types and cloud accounts in scope. The Security Hardening page describes how an engagement runs and what you receive. The patching half starts with an accurate inventory, which a Vulnerability Assessment can help validate.

Frequently asked questions

What is the difference between hardening and patching? Patching installs a vendor fix for a known flaw. Hardening sets a secure configuration against a written baseline.

Does patching count as hardening for an audit? No. PCI DSS and ISO/IEC 27001:2022 both treat them as separate controls with separate evidence.

Which does PCI DSS 4.0.1 put a deadline on, hardening or patching? Patching, in Requirement 6.3.3. Requirement 2 asks for maintained configuration standards, not a deadline.

Can a vulnerability scan prove a system is hardened? Only in part. Hardening evidence is the baseline, a comparison against it, and an exceptions record.

What should a casino show an auditor who asks for both? Baseline, verification date and exceptions register for hardening; inventory, ranking, patch dates and deferrals for patching.

Sources and review

This article describes PCI DSS 4.0.1 Requirements 2 and 6 and ISO/IEC 27001:2022 Annex A 8.8 and 8.9 in general terms, from the published standards' structure and secondary summaries; it cites no statistics, prices or AnySec-original numbers, case results or SLA figures. Author: AnySec Engineering. Published 2026-10-09; last reviewed 2026-10-09.