# FOCTTA Detection - data detection and response (DDR) > Allow, mask or block each query at a decision gateway, then respond with detection rules, playbooks and your SIEM and SOAR. Web page: https://foctta.com/detection This Markdown copy has the same content as the web page. Built 2026-10-14. --- FOCTTA Detection (DDR) Check every query PostgreSQL gateway # A decision on every query to sensitive data, before it runs. FOCTTA Detection checks every query to sensitive data before it runs, inside the database connection, and allows, masks, challenges or blocks it. (DDR \- data detection and response) Then it runs the response playbook and drafts the regulator notification. Your application only changes its connection string. [Book a demo](https://foctta.com/company) See how Detection blocks a query Allow Mask Alert Step-up Break-glass Quarantine Block ALLOW SELECT plan, city FROM customers no identifiers MASK SELECT name, pan FROM customers pan masked BLOCK SELECT \* FROM kyc\_documents name the columns · BLK-7F2C STEP-UP SELECT \* FROM ledger LIMIT 500000 10x normal volume BLOCK SELECT dob, guardian FROM students children's data MASK SELECT email, phone FROM leads phone masked ALLOW SELECT sku, stock FROM inventory no personal data BLOCK COPY customers TO STDOUT mass export ALLOW SELECT plan, city FROM customers no identifiers MASK SELECT name, pan FROM customers pan masked BLOCK SELECT \* FROM kyc\_documents name the columns · BLK-7F2C STEP-UP SELECT \* FROM ledger LIMIT 500000 10x normal volume BLOCK SELECT dob, guardian FROM students children's data MASK SELECT email, phone FROM leads phone masked ALLOW SELECT sku, stock FROM inventory no personal data BLOCK COPY customers TO STDOUT mass export How it works 1. Point your application at the gateway 2. Each query is checked against your rules 3. Allowed, masked, challenged or blocked ## The gateway decides. The database does the masking. Hover or tap a card for detail. The gateway speaks the PostgreSQL protocol today. **Masking inside the query**: Returns masked values, like the last 4 digits. The query is rewritten so the database itself returns masked values: last four digits, masked Aadhaar or a token. **Fail closed, always**: Blocks when it cannot mask safely, or is down. If a query cannot be masked safely, it is blocked with a clear instruction. If the policy engine is down, the gateway denies. **Purpose checked at the query**: No consent for the purpose, no raw data. A query for a purpose without valid consent is masked at the column or blocked, with the reason attached. **One Request ID everywhere**: One ID links the error, decision and audit trail. The same ID in the error, the decision, the audit chain and the SOC ticket, plus a "why was I blocked?" page. **Blocks your apps understand**: A block looks like a normal database error. A blocked query gets a well-formed database error, so existing error handling and retries behave. **Real session kill**: Ends the offending live database sessions. Ends the offending database sessions, matched by the person's hashed identifiers, and says so when none were found. 41 built-in rules ## Rules for Indian data, Indian banks and Indian law. **Pause, copy or test-run any rule** Pause or fork any rule, dry-run a new one against real data before publishing, and publish it only when you are happy with what it would have done. Core data security 11 Banking and financial services 10 Healthcare 5 Cloud 10 DPDPA 5 Core data security · 11 rules Aadhaar outside a vault Section 9 minor data without guardian consent Cross-border personal data without safeguards Publicly exposed personal data Orphan personal data Mass export by a privileged user Mass export over a time window Audit logging disabled Consent-failed queries Purpose drift Schema-mapping reconnaissance Respond ## 15 playbooks that act, and say so honestly when they cannot. Destructive steps wait for two different people. Safe steps run on their own. A step with nothing to run reports "not implemented", never a false green. See the 15 playbooksAadhaar vault escalation Section 9 guardrail Cross-border geofence Breach console pre-fill Session quarantine Lock session, then review Quarantine export Disable user, then notify Block egress destination Revoke encryption grant Re-enable audit logging Force consent check DPIA kick-off Rights request escalation Block minor access **Emergency access, done properly** Emergency access needs a written reason, a time limit of 15 to 240 minutes and two approvers, and ends with a summary. **Breach drafted for you** A confirmed block drafts the incident with the attack chain. Unknown counts read "not yet established", never zero. **Rules you can test first** Dry-run a new rule against real data, see what it would have decided, then publish, pause or fork it. SIEM and SOAR **29 targets, with native delivery to Microsoft Sentinel, Splunk and CEF syslog.** Automatic push on the roadmap Today: test sends, a history per target, audit forwarding. Named targetsSplunk Microsoft Sentinel IBM QRadar Elastic Sumo Logic Securonix Exabeam LogRhythm Google Chronicle Datadog Cortex XSOAR ServiceNow SecOps Tines Webhook CEF syslog Kafka On its own, or together **Detection runs with no other FOCTTA product. Pairing adds depth.** FOCTTA Discovery (DSPM) Recognises the IDs in your tables. (https://foctta.com/discovery) FOCTTA Activity (DAM) Normal behaviour feeds the rules. (https://foctta.com/activity) FOCTTA Consent Checks the purpose people agreed to. (https://foctta.com/consent) ## Put a decision in front of your most sensitive tables. [Book a demo](https://foctta.com/company)