DSPM for AWS & Azure databases
Your auditor will ask about the database
you forgot you were running.
Delayer finds every database in your AWS accounts — all 21 services, including the ones other tools quietly skip — plus 7 Azure database services in the same inventory. It checks each one against 174 controls mapped into 20 frameworks, discovers the regulated data inside it, and produces evidence your auditor can verify without taking our word for anything.
Every number here is countable in the product, and the coverage matrix below is the full, unedited list — including the services where coverage is partial.
The problem
Compliance tooling stopped at the edge of the database.
Cloud posture tools read control-plane configuration — encryption flags, public-access booleans, backup retention. That tells you how a database is configured. It cannot tell you what is inside it, who touched it last night, or whether the engine version has a known exploit. So the questions an auditor actually asks land back on a human with a spreadsheet.
“The confusion isn't really about controls — it's about not knowing what order things are supposed to exist in.”
practitioner, on why audit readiness is hard
“Auditors love asking: show me this policy as it existed six months ago.”
a point-in-time screenshot is not evidence
Both of these are readiness problems, not control problems. A tool that hands you another list of failures makes them worse. What closes an audit is a defensible answer per resource, with history behind it.
What it does
Five questions, answered on every database you own.
Each one is a separate product somewhere else in this market. The point is not that Delayer has five features — it is that the answers are joined to the same asset.
What exists?
Continuous multi-account, multi-cloud inventory. A cross-account read role enumerates all 21 AWS database services across every region and account you enroll — including Keyspaces, Neptune, Timestream, DAX, S3 Tables and S3 Vectors, which generalist tools typically do not enumerate at all. Aurora clusters and their instances collapse into one logical database so counts mean something. Enrolled Azure subscriptions add 7 more services to the same inventory — one table, one compliance page, one report, not a second product bolted alongside.
Is it configured compliantly?
174 controls, 1,823 framework citations, one verdict per resource. One control is one real-world check; frameworks cite it rather than duplicating it — so a single misconfiguration shows up once with one fix, not five times with five near-identical remediations. Findings resolve to pass, fail, not-applicable, manual, or unvalidated — that last one being the product refusing to claim a pass it cannot evidence.
What sensitive data is inside?
34 classifiers across PII, PCI, PHI and secrets. Delayer connects through 17 engine-specific drivers, reads schemas, users and grants, and samples column values — including 11 non-US identifier classifiers (UK NINO/NHS, AU TFN, SG NRIC, IN Aadhaar, BR CPF, CA SIN, JP My Number, CN Resident ID). Findings are counts and confidence scores. Raw values are never stored, and three independent layers refuse to carry them.
Who is touching it?
Activity monitoring across 22 AWS engine identifiers. Engine audit logs, CloudTrail management events, and data events land in one canonical schema, collapsed into per-resource summary windows. Delayer can also turn the engine's own native audit subsystem on for you — reboot-aware and idempotent — across 15 engine families. Azure activity arrives over Event Hubs into that same canonical schema, so "who touched this database" is one query across a mixed estate rather than one per cloud.
Is the engine exploitable?
Patch currency first, CVEs labelled honestly. Two engines run side by side: how many versions behind your cloud's latest you are (authoritative), and NVD-derived CVE matches marked candidate — because AWS silently backports fixes, so a naive CVE match against a version string is a false positive. Forked engines are excluded from CVE matching entirely rather than guessed at. On Azure, evergreen services report platform-managed rather than a fabricated version delta — Microsoft patches them continuously, so there is no number to report and inventing one would be worse than saying so.
And then fix it
Finding the problem is only half the job.
All 174 controls ship a copy-paste fix in five formats. 43 of them also have a machine-executable version, and 22 are switched on today — for those, Delayer will apply the fix for you: one click, with your hand on the switch for every change.
One click, still your decision.
Apply a control's fix from the same drawer that surfaces the finding. Delayer runs it through a dedicated, single-purpose role — an AWS IAM role, or an Azure role assignment — separate from the read and scan grants, with four independent fail-closed kill switches, and confirms success by re-checking the resource's actual posture afterward, never by trusting the API's return value. No auto-rollback surprises: a durable ledger records every step. On Azure that read-back is not a nicety: a 2xx from Azure Resource Manager does not by itself mean the change stuck.
Disruptive changes need a signed permission slip.
Reboot-required fixes, blocking public access, and Multi-AZ failover fire only when you've consented to that specific blast-radius class. Multi-step fixes — stage a parameter, reboot, confirm — run as one sequenced action with a resume-safe ledger, so there are no half-applied states. Nothing runs on a schedule and nothing runs unattended; an operator initiates every action.
Including the fixes that aren't a flag flip.
Patching is covered, not just configuration. Delayer can apply a queued AWS maintenance action, run a minor or major engine-version upgrade, roll a parameter-group change across a cluster readers-first, or merge an audit setting into an existing parameter without stomping what else you had configured. Those are the fixes teams actually defer for months — and the ones a naive read-modify-write silently breaks.
Same behaviour in both deployment modes.
Whether Delayer reaches in from our account or runs entirely inside yours as self-hosted containers, remediation works the same way. Coverage is deliberately incremental: each fix stays dark until it has been validated against a real database — and a fix validated in one mode stays dark in the other until it is proven there too. The set of one-click actions grows conservatively rather than all at once.
Coverage
The whole matrix, including where it's partial.
Most vendors describe coverage in engine families — “PostgreSQL, MySQL, MongoDB.” Here is the actual per-service list, generated from the product's own service registry. Check it against whatever you're evaluating against. Azure is a second table rather than a footnote, and its depth is genuinely narrower — you can see exactly where.
| AWS service | Family | Inventory | Compliance | Data discovery | Activity | One-click fixes |
|---|---|---|---|---|---|---|
| RDS Instances | relational | ✓ | ✓ | ✓ | ✓ | 11 |
| RDS Clusters (Aurora) | relational | ✓ | ✓ | ✓ | ✓ | 7 |
| Aurora DSQL | relational | ✓ | ✓ | ✓ | M | 1 |
| RDS Proxy | relational | ✓ | ✓ | — | M | — |
| DynamoDB | key-value | ✓ | ✓ | ✓ | D | 3 |
| DAX | key-value | ✓ | ✓ | — | M | — |
| Redshift | warehouse | ✓ | ✓ | ✓ | ✓ | 1 |
| Redshift Serverless | warehouse | ✓ | ✓ | ✓ | ✓* | ○ |
| DocumentDB | document | ✓ | ✓ | ✓ | ✓ | 1 |
| DocumentDB Elastic | document | ✓ | ✓ | ✓ | M | ○ |
| ElastiCache | cache | ✓ | ✓ | ✓ | ✓ | 2 |
| MemoryDB | cache | ✓ | ✓ | ✓ | M | 1 |
| Neptune | graph | ✓ | ✓ | ✓ | ✓ | 1 |
| Neptune Analytics | graph | ✓ | ✓ | ✓ | M | ○ |
| OpenSearch | search | ✓ | ✓ | ✓ | ✓ | ○ |
| OpenSearch Serverless | search | ✓ | ✓ | ✓ | M | — |
| Keyspaces (Cassandra) | wide-column | ✓ | ✓ | ✓ | D | 1 |
| Timestream for InfluxDB | time-series | ✓ | ✓ | ✓ | ✓ | — |
| Timestream | time-series | ✓ | ✓ | — | M | — |
| S3 Tables | tables | ✓ | ✓ | ✓ | D | — |
| S3 Vectors | vector | ✓ | ✓ | ✓ | D | — |
| Azure service | Family | Inventory | Compliance | Data discovery | Activity | One-click fixes |
|---|---|---|---|---|---|---|
| Azure Database for PostgreSQL | relational | ✓ | ✓ | ✓ | ✓ | — |
| Azure Database for MySQL | relational | ✓ | ✓ | ○ | M | — |
| Azure SQL Server | relational | ✓ | ✓ | ○ | M | ○ |
| Azure SQL Database | relational | ✓ | ✓ | ○ | M | — |
| Azure SQL Managed Instance | relational | ✓ | ✓ | ○ | M | ○ |
| Azure Cosmos DB | document | ✓ | ✓ | ○ | M | 1 |
| Azure Cache for Redis | cache | ✓ | ✓ | ○ | M | — |
18 of 21 AWS services support in-database data discovery. Three do not, and they say so above. MemoryDB has no slow-log export API, so its activity coverage is management-plane only — that is an AWS limitation, not a roadmap promise.
On the Azure table: all 7 services are at parity for the read pillars — inventory, compliance, exposure and risk scoring, and vulnerability assessment. Data discovery and engine-level activity are live on PostgreSQL Flexible Server and dark elsewhere: the drivers and audit enablers are written, but we switch one on for an engine only after validating it against a live server of that engine, which is the same bar every AWS engine had to clear. Azure management events are subscription-scoped, so enabling them covers every database in the subscription at once. Every Azure one-click runs centrally and has no automated undo — Azure Resource Manager offers no single-call inverse, and refusing beats a reversal that half-applies.
The last column counts one-click fixes only. Every failing control on every service above still ships a copy-paste fix in five formats — the column is about what Delayer will execute for you, which is deliberately a smaller set. A fix appears there only after it has been run against a real database of that type; until then it stays dark, even when the same fix is already live on a neighbouring service.
How it works
Two deployment modes. You pick the blast radius.
The detection logic is identical in both — the parsers, drivers and schemas are byte-mirrored into the customer-deployed images, and four CI gates fail the build if a mirror drifts by a single byte. You don't get a degraded agent.
Cross-account read role
- AWS: one CloudFormation template, external-ID gated
- Azure: one Bicep deployment — an Entra app consent, a Reader role assignment, and a binding tag
Describe*/List*for inventory — no database connection required- Deep scanning is opt-in per capability tier
- Fastest path to a first result
Customer-hosted containers
- Helm chart, ECS Fargate, AKS or Azure Container Apps; up to five containers
- Activity monitoring and remediation are opt-in, off by default
- The controller is the single egress principal
- Credentials and data never leave your account
- Non-root, read-only root FS, default-deny network policies
What leaves your account
Classifier findings are {classifier_id, confidence, match_count, sample_count} — never the matched value. The producer, the receiver and the browser each independently refuse payloads carrying raw values, and that refusal is covered by tests rather than by a promise in a PDF. Evidence bundles are signed with a per-tenant KMS key and include the public key, so an auditor verifies them with openssl without contacting us.
Scope
What Delayer is not.
If one of these is a requirement, we're the wrong tool and you should know that now rather than in week three of a POC.
AWS and Azure managed databases. No GCP, no Snowflake, no SaaS-app data stores. On-prem and self-managed databases only if they're routable from your VPC. Azure depth is narrower than AWS depth and the coverage matrix says exactly where.
Delayer observes and reports. It does not block queries, proxy connections, mask columns, or sit inline with your traffic. It is a detective control.
Delayer never changes your infrastructure on its own. One-click remediation exists for a growing set of controls, but an operator initiates every fix, disruptive changes need explicit per-class consent, and nothing runs on a schedule or unattended.
No LLM analysis, no natural-language querying, no generated summaries. The detection logic is explicit rules you can read and argue with.
The 20 frameworks are what Delayer audits you against. Delayer holds no SOC 2, ISO 27001 or FedRAMP authorization of its own — ask us where that stands.
Databases only. If you need posture for IAM, S3 buckets, EC2 and Kubernetes, keep the platform you have. Delayer goes deeper on the layer it covers.
Pricing
We don't know what this is worth yet.
Everyone in this market hides pricing behind a form. We'd rather show you a number and be told it's wrong. These tiers are provisional anchors, not a rate card — the number and the unit are both genuinely open questions we want argued with.
- Full inventory + compliance
- All 20 frameworks
- Data discovery on request
- Direct line to the person who built it
- Multi-account, multi-region
- Activity monitoring included
- Vulnerability assessment
- Signed evidence bundles
- Runs entirely in your account
- Custom frameworks + classifiers
- Auditor-facing evidence workflow
- Deployment support
The part we actually want to learn
The hard question isn't the number — it's the unit. Per database punishes you for splitting a monolith. Per account punishes consolidation. Per TB scanned makes the bill jump when a table grows, which is exactly when you'd want to scan it. Every one of these is defensible and every one is wrong for somebody.
- Which unit would you actually sign? Per database, per account, per TB, per framework, or flat.
- What's the trigger? An upcoming audit, a blocked enterprise deal, a migration, or something already on fire.
- Which of the five questions would you buy on its own — and which are just nice to have alongside it?
Questions
The things that kill these deals.
What permissions do you need, exactly?
On AWS, for inventory: a cross-account IAM role with Describe*/List* on the database services you enroll, gated by an external ID. On Azure: admin consent for our multi-tenant Entra application, the built-in Reader role at subscription scope, and a delayer-binding tag that proves the subscription is yours to enroll. Both generated policies are derived from the service registry and kept in lockstep by CI checks, so neither quietly widens. Data discovery needs a database connection — IAM auth, a cloud-managed master secret, an Entra database principal you grant SELECT, or credentials you supply — and is opt-in per resource. Write access is always a separate, separately-revocable grant.
How long until I see something real?
Inventory and compliance results land on the first collector pass after you deploy the role — minutes, not a professional-services engagement. Data discovery and activity monitoring are separate opt-in tiers you turn on when you're ready.
We already have a CNAPP. Why would we add this?
Ask your CNAPP for its per-service coverage matrix and compare it to the one above. If it enumerates Keyspaces, Neptune, Timestream, DAX and S3 Vectors, and reads schemas and grants inside them, you probably don't need us. In our experience that list stops at the common engine families — which is a rational product decision for a platform chasing horizontal breadth, and the exact gap we exist in.
What happens if you get breached?
We never hold your data. Classifier findings are counts and confidence scores; the raw values never leave your account, enforced independently at three layers. In the in-VPC deployment, credentials never leave either. The worst case is exposure of your database inventory and posture findings — which is not nothing, and is why the in-VPC mode exists.
Do you support on-prem or other clouds?
AWS and Azure managed databases. Not GCP, not Snowflake, not SaaS-app data stores. On-prem and self-managed databases are reachable only if they're routable from your VPC — over Direct Connect or ExpressRoute — using the manual-credentials path. Azure coverage is real but shallower than AWS: read pillars across all 7 services, in-database scanning and engine-level activity on PostgreSQL Flexible Server today. The coverage matrix above marks every gap.
Are you SOC 2 certified?
Not today. We audit you against 20 frameworks; we hold none of them ourselves yet. If that's a hard blocker for your procurement, tell us — it moves it up the roadmap, and it's exactly the kind of signal this page exists to collect.
Point it at one account and see what it finds.
One CloudFormation template, read-only, external-ID gated. If the findings aren't worth your time, delete the role and we'll have learned something anyway. No sales sequence — the walkthrough is with the person who wrote the evaluator.
Got it.
Thanks — that landed. You'll get a reply from a human, usually within a working day.