Which change was not planned?
A servicing run touches thousands of files on every server. A tool that reports each one buries the single change nobody planned.
Solutions · Banking and finance
Every change, explained, on the servers that matter most.
PCI DSS v4.0 and banking regulation ask for continuous change detection on critical files, and for evidence that a change was authorised. On a fleet that patches every week, that is an operations problem before it is a compliance one.
What is asked of you
Three questions you have to answer.
Who authorised it?
An assessor rarely asks whether a file changed. They ask who changed it, under whose approval, and where that is written down.
Which servers run that version?
When an advisory lands on a Friday evening, the first question is which machines carry that package, and which exact version.
Our answer
What it does on a fleet that patches every week.
Legitimacy before change
The first question is whether the binary is the original, not whether it moved. Binaries, libraries and packages are weighed against the original, including what the operating system shipped.
One servicing run, one alert per server
A Windows servicing transaction and its publisher are recognised, and the whole run folds into one alert per server. A suspicious or malicious verdict is never lowered.
The chain behind the change
A changed file arrives with the user who signed in, still known after sudo, every process in between with its command line, and the change at the end.
Which servers, which version
Search a package across the fleet and narrow to one exact version, or search a file by name, path or hash. Vulnerabilities and end-of-life dates sit on the same inventory.
Approvals where the work happens
Change windows, approval policies and four-eyes review are part of the product, and the ticket reference stays on the record instead of in somebody's mailbox.
On your own servers when the rules say so
Where your regulator keeps in-scope systems and their data in your own country or on your own premises, the path is the self-hosted build: the same product on your infrastructure, activated from a signed licence file.
RuleChange is a question, not an alert.
Patch day is not an incident.
A monthly Windows update rewrites thousands of system files on every server. Each one is weighed before anyone is paged, and the run lands as one alert per server with its evidence attached, so the change nobody planned is the one that stands out.
MEDIUM · Windows servicing: system files changed by Microsoft-signed contentSee the proof: Change is a question, not an alert.Control catalogues
Mapped to PCI DSS and the banking catalogues.
- PCI DSS v4.0
- ISO/IEC 27001:2022
- SOC 2
- NIST CSF 2.0
- BDDK banking IT regulation
Integrity telemetry fills in control statuses while the fleet runs. The mapping is ours; the assessment is your assessor's.
Evidence
What the assessor actually gets.
- 01Every operator action lands in an HMAC-chained audit trail with signed nightly checkpoints.
- 02Reports can be signed with Ed25519 and carry an RFC 3161 timestamp.
- 03The bundle carries its own offline verifier, so whoever checks it does not have to ask us.
- What is handed overAn evidence bundle that can be checked without an account on our console.
Boundaries
What it is not.
It is not a certification. No product is PCI DSS certified; it produces the evidence your assessor asks for.
It does not discover cardholder data or scope a card data environment, and it does not inspect what files contain.
It detects, explains and evidences. Blocking, isolating a host or killing a process is not something it does.
See your PCI DSS evidence on a demo fleet.
A 30-minute walkthrough on servers like yours: change detection on critical files, the approval behind each change and the bundle your assessor receives.
Book a demo