Integrations and Scanning
Connect your databases, object storage, and NoSQL stores to Neostra, scope and schedule scans, and review what the scanner finds and how it classifies it.
An integration connects one of your systems, a PostgreSQL database, an S3 bucket, a MongoDB deployment, and so on, to Neostra so it can be scanned for personal data. Each integration holds its connection credentials, its scan scope, its schedule, and its scan history. Discovered data feeds your inventory, where you review and confirm classifications.
Open Data Inventory > Integrations to see every integration, its status (Connected, Disconnected, Permission Required, or Not completed), brand, and owner. Click the row to open its details, or Add Integration to connect a new system.
Connecting a system only registers it and enables scanning. Whether it is actually scanned, and what parts of it, depends on the Scope and Schedule you configure, or an ad-hoc scan you start yourself.
Supported integrations
Click Add Integration to browse the catalogue of supported systems. Each card shows its name and a short description; select one to read its setup instructions before you proceed to the connection form.
| Type | What you provide |
|---|---|
| PostgreSQL | Host, port (defaults to 5432), database, schema, username, password |
| MySQL | Host, port (defaults to 3306), database, username, password |
| MongoDB | Host, port (defaults to 27017), database, username, password, optional auth source, optional TLS |
| Amazon S3 | Region, access key, secret key, optional bucket name to scope to a single bucket, optional custom endpoint URL |
| Amazon DynamoDB | Region, access key, secret key, optional custom endpoint URL |
Neostra never asks for a raw connection string. You always fill in discrete fields, host and port rather than a JDBC URL, or a URI's individual parts, and Neostra assembles the connection itself when it needs to reach your system.
Add an integration
Choose a supported integration
Select a type from the catalogue, review its instructions, and click Add.
Fill in the details
Enter a Title, an optional Description, an Owner, and any Brands the integration belongs to. Title and owner are required.
Enter credentials
On the new integration's Credentials tab, fill in the connection fields for the chosen type. Password, secret key, and access key fields are masked and write-only: once saved, they are never shown back to you, and leaving them blank on a later edit keeps the existing value.
Test Connection
Click Test to verify Neostra can reach your system with the entered credentials before you save. A confirmation or failure message tells you whether the connection worked.
Save
Click Save to store the credentials. The integration's status updates based on whether the connection succeeds.
You can edit the title, description, owner, and brands at any time from the integration's Details overview.
Scope
The Limits tab controls exactly which parts of the connected system are scanned. What you name here depends on the integration type:
| Type | Top-level unit | Sub-level |
|---|---|---|
| PostgreSQL, MySQL | Table | Columns |
| MongoDB | Collection | Fields |
| DynamoDB | Table | Attributes |
| Amazon S3 | Prefix | Not applicable |
Inclusions: if you add anything here, only those tables (or collections, or prefixes) are scanned, nothing else. Leave the sub-level field empty to include the whole unit, or list specific columns, fields, or attributes to include only those.
Exclusions: units and sub-units listed here are never scanned, regardless of inclusions. Exclusions always win over inclusions.
A primary-key or identifier field you exclude is still read for pagination purposes, it is simply never scanned for PII. Excluding it does not stop the scan from working through the rest of the table.
If you leave scope empty entirely, the integration scans everything it can discover.
Scanner
The Scanner tab is where you run an on-demand scan and see the most recent result at a glance:
- Start runs a one-time scan immediately with the integration's current scope. The Stop and Pause controls exist alongside it but do not currently stop a running scan on the backend.
- Most Recent Scan shows Status, Type, Started, Next Scan, Duration, Warnings, and Errors for the last scan (or the one currently running).
- A status chip reads Queued, Processing, Ready, or Never Run, plus a count of excluded items if your scope has exclusions.
The first time you finish connecting an integration, Neostra automatically queues an initial full scan so you have a baseline before you set up anything else.
Schedule
The Schedule tab sets a recurring cadence so the integration is scanned automatically without you starting it each time. Each integration can have one schedule.
Add Schedule
Choose a Frequency: Daily, Weekly, or Monthly.
Set the timing
Weekly asks for a day of the week; Monthly asks for a day of the month (1 to 31; if a given month is shorter than the day you chose, the scan runs on that month's last day instead). Both ask for a Time of day and a Timezone.
Save
The schedule shows its next run time immediately.
Once created, the schedule card shows Next Run, Last Run, and the status of the last scheduled scan (Completed, Failed, In Progress, Queued, or Never Run). Use Pause and Resume to stop and restart the cadence without deleting it, Edit to change the frequency or timing, and Delete to remove the schedule entirely.
Scan History and Scan Findings
The Scan History tab lists every scan run for the integration: Started At, Completed At, Duration, Trigger (manual or scheduled), Scanned Entities, and Status (Queued, In Progress, Completed, or Failed). Filter by status or by a date range. A scan is marked Failed only if none of its scanned items succeeded; if at least one item completed even while others failed, the scan is marked Completed.
Click into a scan to open Scan Findings, a filterable list of everything the scan detected:
| Column | What it shows |
|---|---|
| Resource Path | The table, collection, or object where the finding was detected |
| Detector | Which detection method found it |
| Category | The classification category the finding belongs to (see below) |
| Type | The specific data type detected, for example Email Address or Aadhaar Number |
| Detection Score | Confidence in the detection, shown as a percentage |
| Excerpt | A short snippet around the match, when your scanner configuration retains one |
Filter findings by Type, Category, or Resource Path.
Review and confirm what a scan found, and see it alongside the rest of your data map, in Inventory.
What is detected and how it is classified
The scanner recognizes a broad set of personal and sensitive data types, including common identifiers (names, email addresses, phone numbers, dates of birth, IP addresses), financial data (credit and debit card numbers), and a set of India-specific government and financial identifiers: Aadhaar number, PAN, GSTIN, IFSC bank branch code, UPI or wallet ID, voter ID, vehicle registration, and passport number. Detection combines pattern-based recognition for structured identifiers with broader language-based recognition for things like names and locations.
Each detection is mapped to a data object (for example, "PAN" or "Email Address") and a category (for example, Government IDs, Financial, Identifiers, Health & Biometric, Online/Tracking). From there it carries a risk score from 1 to 10 with a label, Low, Low-Medium, Medium, Medium-High, or High, that reflects how sensitive that kind of data typically is. Government IDs, financial account numbers, health data, and biometric identifiers are generally scored High; general identifiers like names and job titles score lower.
Scanner configuration: Scan PII Evidence
Under Data Inventory > Configuration > Scanner, you control how much evidence the scanner keeps for each detection it makes. This setting applies across all your integrations.
Choose one of three trace-handling modes:
| Mode | What it stores |
|---|---|
| Trace metadata only | Detection metadata (type, category, location, score) with no excerpt of the underlying data. |
| Redacted trace | A redacted excerpt kept alongside each detection, bounded by a context radius you set (the number of characters kept around the match). |
| Hash trace | A stable hash of each detection instead of any excerpt, useful for counting unique instances of PII without retaining the values themselves. |
You also choose which detection signals are enabled: Language Model (broader, context-aware detection) and Regex (pattern-based detection for structured identifiers). At least one must stay enabled.
Choose the trace-handling mode with care. Trace metadata only gives you the least visibility into what was actually found; Redacted trace gives you a limited excerpt to help you verify findings; Hash trace lets you confirm the same value recurs without ever storing it.
Credential security
Passwords, secret keys, and access keys are write-only fields. Once saved, Neostra never returns their values to the UI. Editing an integration's credentials without changing a masked field keeps the previously saved value; you only need to fill in a masked field when you are actually rotating it.