Customer data security guide
How do you securely expose business data to customers?
Expose selected business data through a controlled customer application boundary. Identity, organisation membership, record authorisation, allowed fields, source-system access and operational monitoring must work together on every request.
The direct approach
Start with the customer task and list only the information and actions needed to complete it. Put a server-side application layer between the customer and each ERP, CRM, warehouse, document store or operational database. That layer authenticates the user, resolves the organisation context, authorises the resource, filters properties, validates actions and records sensitive activity.
Do not rely on a hidden button, a customer identifier supplied by the browser, an unpredictable record ID or network access alone. OWASP identifies broken object-level authorisation as a leading API risk, while NIST zero trust guidance places the focus on explicit access to resources rather than implicit trust based on network location.
01
Define the boundary before selecting technology
| Question | Decision required |
|---|---|
| Who is the customer? | Organisation, account, branch, contract and user membership model |
| What may they see? | Allowed resource types, records, fields, files, periods and derived measures |
| What may they do? | Read, search, download, upload, submit, approve, correct or query |
| Where is the truth? | Owning system for each value, state transition and business rule |
| What can fail? | Identity, mapping, source availability, stale data, duplicates and downstream rejection |
| Who responds? | Named owner for access, data quality, exceptions, security events and customer support |
The boundary is a business and security contract. A gateway or identity provider can support it, but neither tool can decide the correct customer scope on its own. For a Snowflake-backed service, compare the available external customer access patterns.
02
Make the access decision in a fixed sequence
- Verify identity. Validate the session or token, issuer, audience, expiry and required authentication strength.
- Resolve membership. Load an active server-side relationship between the user and the customer organisation.
- Authorise the action. Decide whether that role may perform this operation on this resource in its current state.
- Constrain the query. Apply customer scope inside the repository, service or policy layer before retrieving data.
- Minimise the response. Return approved customer-facing properties rather than serialising internal records.
- Record sensitive activity. Preserve actor, organisation, object, action, outcome and correlation context.
04
Control the data throughout its customer-facing lifecycle
Select
Minimum useful fields
Publish an explicit response model and exclude internal notes, identifiers, credentials and operational metadata.
Transform
Customer meaning
Translate codes, units, dates and statuses into stable concepts without hiding known data limitations.
Store
Governed copies
Define encryption, ownership, freshness, reconciliation, retention and deletion for caches and read models.
Export
Controlled files
Limit rows and fields, authorise downloads, use short-lived links and record sensitive export events.
Data minimisation also improves clarity. A customer interface is easier to understand and maintain when it exposes a deliberate contract instead of mirroring every internal column.
05
Protect the internal systems behind the application
- Use separate, least-privilege integration identities rather than shared staff credentials.
- Keep secrets and connection details on the server and rotate them through an approved mechanism.
- Set timeouts, bounded retries, concurrency limits and circuit-breaking behaviour.
- Validate downstream responses and treat integrated services as another trust boundary.
- Use queues for long-running or failure-prone actions and provide honest status to the customer.
- Prevent duplicate writes with idempotency or a business-level request key.
- Separate customer query load from fragile operational systems through a read model when justified.
The client portal API architecture guide covers stable contracts, orchestration, failure behaviour and observability in more detail.
06
Secure access continues after release
Operate customer data access as a service with accountable owners. Review invitations, role changes, dormant accounts, support impersonation, unusual downloads, repeated denials and integration credentials. Monitor both technical health and customer workflow outcomes.
| Signal | Question it should answer |
|---|---|
| Authorisation denials | Is policy working, misconfigured or being probed? |
| Export activity | Who downloaded which customer dataset and when? |
| Source errors | Which system is preventing customer completion? |
| Mapping failures | Which records cannot be assigned to a customer safely? |
| Access reviews | Do active users and roles still match real relationships? |
07
Deliver one secure customer slice
- Choose one customer group and one information need.
- Document the source owner, customer mapping and allowed fields.
- Threat-model cross-customer access, exports, support access and source failure.
- Prototype identity, one difficult policy and one real source query.
- Build customer experience, administration, audit and exception handling together.
- Test with positive, negative, cross-tenant and stale-membership scenarios.
- Pilot with representative users and review logs before expanding access.
For a broader delivery path, use the client portal implementation checklist.
Sources
Primary references
Questions
Frequently asked questions
What is the safest way to expose business data to customers?
Place a controlled customer application and API boundary in front of internal systems. Authenticate the user, resolve their active organisation and role, authorise every requested object and field, minimise the response, and monitor the complete access path.
Can customers query an internal database directly?
Direct database access is rarely appropriate for customer applications. It exposes internal schema and creates difficult security, performance, change-management and support obligations. Use a purpose-built API, semantic model or customer-facing read model instead.
Is a VPN enough to secure customer data access?
No. Network location should not replace resource-level identity and authorisation. The application must still decide which organisation, record, property and action each authenticated user may access.
Should customer-facing data be copied?
Sometimes. A scoped read model can improve performance, simplify the customer model and isolate source systems. The team must define ownership, freshness, reconciliation, retention and deletion for every copy.
How should sensitive exports be handled?
Generate exports from a tenant-scoped server-side query, limit fields and volume, store files temporarily, authorise every download, use short-lived access links, record the event and expire the file according to policy.
Design the access boundary
Bring the customer roles, data sources and highest-risk records.
LCR can help define a secure external data model, integration path and first customer workflow without exposing the internal system directly.