This document describes the security controls that UDISOFTBOX CONSULTORIA E TECNOLOGIA LTDA ("INGESTIA") maintains on the ingestia.io platform. It exists to be read by whoever evaluates a vendor — security, legal, procurement — and by any customer who wants to know how their data is protected.
Every measure below corresponds to an implemented control. Nothing here is aspiration: what does not yet exist is in section 13, named.
1. Shared responsibility
INGESTIA protects the Platform. The Customer protects what sits on their side.
| INGESTIA's responsibility | Customer's responsibility |
|---|---|
| Isolation between customer environments | Who gets access to the environment, and with which role |
| Encryption of the credentials the Customer registers | Password strength and second-factor activation by their users |
| Audit trail of actions on the Platform | Reviewing that trail and acting on what it shows |
| Availability and recovery of the Platform | Security of their own data sources, networks and devices |
| Cost and query guardrails | Deciding what data enters the Platform, and whether it may |
A Platform control does not substitute for security at the source. An exposed source stays exposed after it is connected.
2. Access, identity and roles
- Passwords are stored as a cryptographic derivation (scrypt), never in readable form. INGESTIA has no way to read anyone's password.
- Second factor (MFA) via authenticator app (TOTP) is available for any account. Once enabled, the code is required on password sign-in as well — enabling it is the user's or the environment administrator's decision.
- Single sign-on (SSO) through the udiApps account, for those already in the ecosystem.
- Automated provisioning (SCIM 2.0) for customers who manage users from a corporate directory: create, update and deactivate a user without going through our desk.
- Roles and permissions: five roles (owner, administrator, member, viewer and organisation administrator) over a closed list of 32 actions. A viewer does not run, export or spend; the check runs on the server, on every action, not in the screen.
3. Isolation between customers
This is the control that matters most in a data product, and so it is the most explicit one:
- each customer has their own datasets in the analytical warehouse, named from an exclusive prefix;
- infrastructure permissions are scoped to that prefix;
- a query that tries to reach an address outside the authorised prefix is refused before it runs — it is not filtered afterwards;
- the result cache is segregated per customer: one environment's answer is never served to another;
- the destination of each query does not come from the browser's request, but from the dashboard or model that originated it — a request does not choose which environment to read from.
4. Encryption
- In transit: TLS across all access to the Platform and to our programming interfaces.
- At rest, for credentials: everything the Customer registers as a secret — source database password, service key, API token and the Customer's own AI key — is encrypted with AES-256-GCM before it reaches the database. The encryption key lives in a server environment variable and is not reachable from the browser.
- A secret does not come back. The interface never redisplays a stored secret: at most it shows the last four characters for recognition. Secrets are also never written to execution logs.
- At rest, for business data: encryption managed by the storage infrastructure, as set out in the Subprocessor List.
5. Audit trail
Every relevant action on the Platform is recorded with author, action, resource, moment and — where applicable — the SQL executed and the cost of that execution. The trail is visible to the Customer inside their own environment and is kept for 730 days, as set out in the Data Retention Policy.
The presence of SQL in the trail has a privacy consequence, and it is declared: a query may contain a filter value that is personal data. That is described in the Privacy Policy, and it is why the trail has a deadline and automatic purging.
6. INGESTIA's administrative access
Saying "restricted access" without saying what it reaches informs nobody. So:
- the INGESTIA team has an administrative access mechanism that allows opening a customer's environment to provide support and diagnose a problem;
- it is limited to super-administrator accounts, controlled by a server environment variable — it is not granted through a screen or an invitation;
- its use is recorded in the audit trail;
- it is not used for any purpose other than support, operation and security of the Platform.
What does not yet exist: automatic notification to the Customer when that access occurs. It is in section 13.
7. Resilience and recovery
- Analytical warehouse: recovery of a previous state for seven days (time travel), which covers deletion or mistaken transformation performed by the Customer themselves.
- File landing zone: object versioning — overwriting does not destroy the previous version.
- Metadata database: backup and point-in-time recovery, through the managed service described in the Subprocessor List.
- Health check: the Platform exposes a deep check that reports the real state of each capability. In production, a path with no configured credential fails visibly instead of simulating success — an architectural rule, with a test that enforces it.
8. Execution guardrails
- Per-query cost ceiling: execution is refused by the engine when it would exceed the maximum authorised data volume, before generating any cost.
- Named parameters in SQL generation — a defence against injection through a filter value.
- Rate limiting on sensitive points (authentication, public forms, integration interfaces), distributed across instances.
- Browser security headers, including a content security policy (CSP) per application area and framing restrictions.
9. Development and change
- All Platform code is covered by an automated suite run before every release, with specific guards for the rules that have already caused damage — among them the byte-for-byte freezing of the query engine's output and the prohibition on any path that fakes success in production.
- Database schema change is additive and versioned in a migration.
- Formats saved by the Customer (dashboard, filter, theme) use a versioned envelope with mandatory reading of the previous version: an update of ours does not destroy their configuration.
10. Vendors
The role, purpose, data involved and country of each vendor are set out in the Subprocessor List, kept public and up to date. A new material vendor is announced at least 15 days in advance, as set out in the Data Processing Agreement (DPA).
When the Customer registers their own AI key, the AI provider it serves is not an INGESTIA subprocessor: the contract and the prompt retention policy are between the Customer and that provider.
11. Security incidents
Once an incident involving the Customer's personal data is confirmed, INGESTIA notifies without undue delay and, whenever feasible, within 24 hours, with whatever is available: nature, estimated categories and volume, affected data subjects, containment, risks and point of contact — and updates as the investigation advances.
Communication to the Brazilian data protection authority (ANPD) and to data subjects is the Customer's decision, as controller, within the applicable regulatory deadline. INGESTIA supports the investigation and the communication.
12. Penetration testing and flaw reporting
Penetration testing, scanning or load testing against the Platform requires prior written authorisation — requests to seguranca@ingestia.io.
Anyone who finds a flaw in good faith should report it through the same channel. INGESTIA does not treat a good-faith report as a breach of the Acceptable Use Policy. The procedure and the commitment are in the Vulnerability Disclosure Policy.
13. What this document does NOT claim
This section exists because a security document that only lists virtues is not information but advertising — and because claiming a certification one does not hold is, on top of everything else, a false statement.
- INGESTIA holds no ISO/IEC 27001, SOC 2 or equivalent certification. No material of ours claims otherwise.
- There is no independent penetration test report available for sharing as of this date.
- The administrative access described in section 6 does not generate automatic notification to the Customer. It is audited; the Customer has to consult the trail.
- There is no contractually committed availability percentage. What exists is a response deadline and internal objectives, described in the Service Level document (SLA) — and the reason there is no percentage is written there: there is no persisted measurement series to support one.
- Credential encryption at rest uses a key held in an environment variable, not a managed key custody service with automatic rotation.
When any item above changes, it leaves this section and enters the corresponding one, on the same date the control begins to exist.
14. Contact
Security: seguranca@ingestia.io · Privacy and data subjects: privacidade@ingestia.io · Data Protection Officer: Encarregado de Dados (DPO) — encarregado@ingestia.io