How to protect customer data (PII and financial data) in a SaaS or fintech

The threat model of a SaaS that custodies third-party data

When a SaaS or fintech stores its customers' PII and financial data, it takes on the role of processor (a controller-processor, in LGPD terms) of data that is not its own. This changes the threat model: the attacker is not just after your operation, but after the aggregate data of all your tenants concentrated in a single platform. A single compromise can expose thousands of data subjects at once, and the surface includes application credentials, API keys, internal administrative access, and the cloud provider's control plane itself.

NIST SP 800-53 and the NIST Cybersecurity Framework organize this defense into functions (Identify, Protect, Detect, Respond, Recover), and the principle that runs through all of them is defense in depth: no single control should be the only thing between the attacker and the data in cleartext. OWASP, in the application Top 10 (A02:2021 Cryptographic Failures, A01:2021 Broken Access Control) and in its cheat sheets, describes the points where SaaS applications typically fail — almost always in key management, access control, and isolation, not in the choice of cipher algorithm.

For the rest of this article, the focus is technical and preventive: the concrete layers that reduce the impact of a compromise, in the order they tend to be attacked. Legal compliance (LGPD) is the context, but the goal here is the technical protection of the data, not documentary satisfaction of the regulator.

Encryption in transit and at rest, and the key management that matters

Encryption in transit is the most mature and least negotiable control: TLS 1.2 as a minimum, preferring TLS 1.3, with modern cipher suites, HSTS, and disabling obsolete protocols and ciphers (SSLv3, TLS 1.0/1.1, RC4, 3DES). This applies to client-server traffic and also to internal traffic between microservices and between the application and the database — the internal perimeter is not trusted by default. The OWASP Transport Layer Security Cheat Sheet and the CIS benchmarks detail the secure configuration.

At rest, AES-256 (GCM for application data, with authentication) is the practical standard, and most providers offer transparent volume and database encryption. The critical point, however, is not the cipher: it is where the key lives. Keys embedded in code, in cleartext environment variables, or in configuration files nullify everything else. The recommendation of NIST SP 800-57 (key management), and consolidated practice, is to use a dedicated KMS (AWS KMS, Google Cloud KMS, Azure Key Vault, or an HSM) with envelope encryption: the data key encrypts the data, and the KMS master key encrypts the data key, without ever leaving the module.

Three disciplines should apply to the KMS. Automatic key rotation at a defined interval, with versioning that allows decrypting old data. Separation of duties, so that whoever operates the application is not whoever administers the master keys, and so that decryption access is authorized by policy and logged. And field-level encryption for the most sensitive data (tax IDs, banking data, customer secrets), so that even a full database dump does not reveal the content without access to the corresponding key.

It is worth distinguishing what each layer protects. Disk encryption protects against physical loss and improper media disposal. Transparent database encryption protects against direct access to the file. Only field-level encryption, with the key outside the database, protects the data against a compromised application credential or a successful SQL injection — which is the most likely scenario in a SaaS exposed to the internet.

Tokenization and masking: reducing what exists to be stolen

The most effective way to protect a sensitive datum is not to have it where it does not need to be. Tokenization replaces the real data (card number, tax ID, bank account) with a token that has no mathematical value outside the vault that maintains the mapping. The application, the logs, and most of the database come to operate on tokens; the original data is concentrated in a single, tightly controlled component. For card data, PCI DSS treats tokenization as a central scope-reduction mechanism, and the same reasoning applies to any high-value PII.

Masking acts on exposure: when displaying, exporting, or using data in non-production environments, only what is necessary is shown (the last four digits, for example) or a realistic substitute value. Development, staging, and analytics environments should not receive real PII — anonymizing or pseudonymizing data before it leaves production eliminates a recurring source of leaks caused by weak controls in secondary environments.

These controls reinforce minimization: every field collected and retained widens the surface. It is worth auditing what is truly necessary, defining a retention period per data category, and implementing automatic purging at the end of the term. Data that does not exist cannot leak, and data already disposed of under a clear policy reduces both technical risk and exposure in the event of an incident.

Multi-tenant isolation, access control, and auditing

In a multi-tenant SaaS, leakage between customers is one of the most serious and model-specific failures. There are three main strategies: a database per tenant (greatest isolation, highest operational cost), a schema per tenant, and a shared table with a tenant identifier and per-row segregation. When using the shared approach, control cannot depend solely on the application layer remembering to filter by tenant: Row-Level Security in the database, applied mandatorily, guarantees isolation even if a query forgets the clause. Every code path that touches data must be validated against the tenant-confusion scenario.

Access control follows the least-privilege principle of NIST SP 800-53 (the AC family) and CIS Controls v8: each identity, human or service, receives only the access it needs, for as long as it needs. For sensitive data, administrative access should be just-in-time and approved, with phishing-resistant MFA, and service accounts should have short-lived credentials rather than static keys. Well-modeled RBAC or ABAC prevents a first-level support agent or a batch job from having too broad a reach.

Auditing closes the loop. Every read and write of sensitive data, every administrative access, and every decryption operation should generate a record with identity, resource, action, and timestamp, in an immutable, centralized trail beyond the reach of whoever is being audited. Without it, improper access is indistinguishable from legitimate use, and the NIST CSF Detect function has no raw material. Audit logs are also the input that allows detecting slow exfiltration and internal credential abuse before they escalate.

Data leak prevention and detection

Even with encryption, tokenization, and restricted access, data escapes through side channels: secrets committed to repositories, API keys exposed in logs or error responses, unmonitored bulk exports, and misconfigured databases or buckets exposed to the internet. Data loss prevention (DLP) and continuous secrets scanning across code and infrastructure cover much of these vectors, as do storage configuration review and cloud posture hardening (CSPM).

Detection complements prevention. Access behavior monitoring (anomalous read volumes, off-hours access, exfiltration patterns) and event correlation in a SOC allow you to react while the incident is still containable. And because part of the leaked data only surfaces later — credentials and databases for sale in forums and marketplaces — monitoring for exposure across external sources and the dark web shortens the time between the leak and the response, allowing you to rotate credentials and notify before the data is widely exploited.

This is where Decripte acts as a technical partner: monitoring and SOC for detection and response, dark web surveillance to identify exposed credentials and data belonging to your organization and your customers, and preventive security to close configuration and access gaps before they become an incident. For teams structuring this layer, Decripte offers a free Threat Management plan, a starting point for mapping exposure at no initial cost.

Practical checklist

1. 1

   1. Map and classify sensitive data

   Inventory where PII and financial data are collected, transit, and persist (databases, caches, queues, logs, backups, non-production environments). Classify by sensitivity and define the required handling for each category before applying controls.

2. 2

   2. Enforce encryption in transit

   Require TLS 1.2+ (preferring 1.3) with HSTS on external traffic and also between internal services and databases. Disable obsolete protocols and ciphers following the OWASP TLS Cheat Sheet and the CIS benchmarks.

3. 3

   3. Centralize keys in a KMS

   Migrate embedded keys to a KMS or HSM with envelope encryption, automatic rotation, versioning, and separation of duties between application operation and key administration. Apply field-level encryption to the most sensitive data.

4. 4

   4. Tokenize and mask

   Replace card numbers, tax IDs, and banking data with tokens, keeping the real data only in the vault. Mask on screens, exports, and logs, and remove or pseudonymize PII from development and analytics environments.

5. 5

   5. Ensure isolation between tenants

   Choose the isolation strategy explicitly and, in shared models, apply Row-Level Security in the database. Include tests that validate that no code path returns another tenant's data.

6. 6

   6. Apply least privilege and auditing

   Model RBAC/ABAC with just-in-time access and phishing-resistant MFA for sensitive data. Use short-lived credentials for services and log every read, write, and decryption in an immutable, centralized audit trail.

7. 7

   7. Monitor for leaks and exposure

   Deploy DLP and secrets scanning, review the configuration of exposed buckets and databases, and establish continuous monitoring of anomalous access and dark web exposure to shorten incident response time.

Frequently asked questions