PatchMortem is built for Indian banking, insurance, and NBFC infrastructure teams — where a missed rollback is not just downtime, it is a compliance finding.
Enterprise patch management has a gap: the tools that deploy patches do not handle failures. SCCM, Intune, and Ansible will all tell you a patch failed. None of them tell you why, and none of them will put the server back the way it was.
In regulated environments the consequences compound. A failed patch on a production cluster means an outage. An outage during a change window means a compliance finding. A compliance finding means an RBI audit observation. The chain is well understood by every VP of IT Operations in Indian banking. The tooling to break it did not exist.
PatchMortem was built to close that gap: automated classification, automated rollback, and a cryptographic audit trail that an RBI inspector can read without logging into your infrastructure.
PatchMortem is designed ground-up against RBI IT Framework 2023, the SEBI Cyber Security Circular, and IRDAI Information Security Guidelines — not adapted from a Western product after the fact. All customer data is stored and processed in AWS ap-south-1 (Mumbai).
| RBI IT Framework 2023 | Audit chain designed for Section 4.2 evidence requirements |
| SEBI Cyber Security Circular | Change control evidence and access logging aligned |
| IRDAI Info Security | Applicable to insurance and NBFC deployments |
| PCI DSS 6.3 | Compliance scope drives approval tiers automatically |
| Data residency | AWS ap-south-1 (Mumbai) — no cross-border replication |
The three things a bank's IT operations and compliance functions actually need from a patch failure.
PatchMortem knows the difference between a dev box and a PCI-DSS-scoped production cluster. Approval tiers, rollback policies, and notification routing adjust automatically based on compliance scope — no manual classification by your L2 team.
Any action that changes the state of a production host requires change board approval, and both approvers are written into the audit chain with timestamps. Your change control evidence is generated as a by-product of the work, not reconstructed afterwards.
Compliance exports for RBI, PCI-DSS, SEBI, and IRDAI are generated from the audit chain on demand. The inspector verifies the chain end-to-end without being given access to your infrastructure.
Most patch failures in a bank happen on the systems that matter most: failover clusters running core banking, payments, and database workloads. PatchMortem detects cluster topology before it takes any action.
| Windows | Windows Failover Clustering (WSFC) — ACTIVE and PASSIVE node roles identified before remediation |
| Linux | Pacemaker cluster state validated prior to any package action |
| Database | SQL Server Always On availability groups detected; replica health confirmed |
| Load balancing | Network Load Balancing membership checked before a node is taken out of service |
Quorum is checked before remediation, and peer nodes are held. A rollback should never take out the cluster it was meant to protect.
The PatchMortem agent is a code-signed binary that collects patch state and servicing logs. It initiates outbound TLS only — there is no inbound listener and no open port on your estate. Remediation is off until you enable it, per policy, per host group.
Full detail on agent behaviour, encryption, access control, and audit chain integrity is on the security page.
We do not run six-month evaluations. Deploy the agent on one host group — typically 25 to 50 servers with a known failure history — in read-only mode. We triage every failure in your next patch window against your own servicing logs and hand you the root causes, with the rollback we would have executed and why.
Compare that against what your team spent on the same window, and compare the audit output against what your compliance function currently submits. If the answer is not obvious, we would rather you did not buy it.
30 minutes with an engineer on your actual patch estate. No slides. No vendor pitch.