Data Security, Privacy, PII, and Data Classification Model

1. Core Idea

Enterprise data model bukan hanya tentang struktur entity dan relationship. Data model juga harus menjawab:

Data mana yang sensitif, siapa boleh melihatnya, bagaimana disimpan, bagaimana dikirim, bagaimana dimasking, bagaimana diaudit, dan kapan harus dihapus/dibatasi?

Dalam CPQ / Quote / Order / Billing / Telco BSS/OSS, banyak data bersifat sensitive:

• customer identity,
• contact data,
• billing address,
• tax identifier,
• payment method reference,
• invoice/payment status,
• quote pricing,
• discount,
• margin/cost,
• product/service configuration,
• site/location,
• IP/resource/network identifier,
• approval evidence,
• audit comments,
• usage data.

Mental model:

Data security is not only infrastructure. It must be reflected in the data model through classification, access scope, masking rules, encryption boundaries, auditability, retention, and minimization.

2. Why Data Security Modelling Matters

Tanpa security/privacy modelling yang eksplisit:

• margin/cost bocor ke sales/customer user,
• billing address muncul di event umum,
• payment reference masuk application log,
• customer site/location terlihat oleh user dari subsidiary lain,
• support user melihat data yang tidak perlu,
• invoice data dikopi ke analytics tanpa masking,
• audit evidence menyimpan PII berlebihan,
• usage data bisa mengungkap perilaku customer,
• service/resource inventory mengekspos network topology,
• data deletion request tidak bisa dipenuhi karena data tersebar tanpa lineage.

Security bukan hanya @RolesAllowed. Security harus mempengaruhi entity, field, DTO, event, read model, report, audit, and retention.

3. Data Classification

Klasifikasi data membantu menentukan kontrol.

Example classification:

One field can have multiple tags:

billing_contact_email = PII + CUSTOMER_CONFIDENTIAL
margin_amount = RESTRICTED + COMMERCIAL_SENSITIVE
ip_address = SECURITY_SENSITIVE + CUSTOMER_CONFIDENTIAL

4. Data Classification Metadata Model

Classification can be documented in metadata.

data_classification_rule
- id
- entity_type
- field_path
- classification
- sensitivity_level
- masking_policy
- encryption_required
- export_allowed
- event_publish_allowed
- retention_policy
- owner_group

Example:

entity_type = Quote
field_path = marginAmount
classification = RESTRICTED
masking_policy = HIDE_UNLESS_DEAL_DESK_OR_FINANCE
event_publish_allowed = false

This metadata can feed:

• code review,
• DTO generation,
• API field filtering,
• analytics governance,
• audit review,
• security testing.

5. PII and Personal Data

PII examples:

• name,
• email,
• phone,
• address,
• government/tax ID,
• user identifier,
• IP address in some jurisdictions/contexts,
• location coordinates,
• customer contact notes.

In enterprise B2B, individual contact data appears in:

• quote contact,
• billing contact,
• installation contact,
• site access contact,
• approval actor,
• support contact,
• audit actor,
• user identity.

Model contact data separately where possible and reference it by ID instead of duplicating across every entity.

6. Sensitive Commercial Data

Commercial-sensitive data includes:

• cost,
• margin,
• target margin,
• discount threshold,
• approval threshold,
• internal price floor,
• competitor notes,
• non-standard contract terms,
• renewal risk,
• credit risk,
• deal desk comments.

Not every user who can view quote should see these fields.

Possible permission split:

VIEW_QUOTE
VIEW_QUOTE_PRICE
VIEW_DISCOUNT
VIEW_MARGIN
VIEW_COST
VIEW_APPROVAL_EVIDENCE

DTO and query layer must honor field-level access.

7. Billing and Payment Data

Billing data is sensitive:

• billing account,
• billing address,
• invoice,
• payment status,
• payment method token/reference,
• tax identifier,
• credit status,
• dunning status,
• adjustment/credit note.

Controls:

• do not store raw card/bank data unless compliant and required,
• use token/reference from payment provider or billing system,
• mask payment references,
• restrict invoice/payment access,
• audit billing data access/change,
• avoid billing details in broad events.

Example:

payment_method_reference = tokenized/external reference
display_value = ****1234
raw_payment_data = not stored

8. Service, Resource, and Network-Sensitive Data

Telco/BSS/OSS systems may store:

• service ID,
• circuit ID,
• router serial number,
• SIM/ICCID/IMSI-like identifiers,
• IP address,
• VLAN,
• port,
• network area,
• resource capacity,
• site coordinates,
• installation access instruction.

This data can reveal customer operations or infrastructure topology.

Controls:

• restrict resource-level view,
• mask network identifiers in support UI when not needed,
• avoid resource details in general analytics,
• secure events containing resource identifiers,
• audit manual changes,
• separate commercial product view from technical resource view.

9. Data Minimization

Data minimization means storing only what is needed.

Questions:

• Does this service need full billing address or only billing account ID?
• Does event need customer email or just customer ID?
• Does analytics need individual contact or aggregated count?
• Does audit need full payload or hash/reference?
• Does read model need margin/cost or only price total?

Principle:

Copy references and snapshots intentionally. Do not copy sensitive fields everywhere for convenience.

10. Field Masking

Masking examples:

Masking policy should depend on:

• actor role,
• data classification,
• purpose,
• channel,
• environment,
• export/reporting context.

Never rely only on frontend masking. Backend/API must enforce it.

11. Encryption and Tokenization

Encryption helps protect stored data but does not solve access control.

Patterns:

Example:

tax_id_encrypted
tax_id_hash_for_matching
tax_id_masked_display

Be careful: encrypted fields are harder to query. Use hash/index token where matching is needed.

12. Secrets Are Not Domain Data

Never store secrets as ordinary business fields.

Examples to avoid:

• API keys in integration table payload,
• password in user table,
• OAuth token in audit metadata,
• private key in event payload,
• downstream credential in JSON config.

Use secrets manager/secure vault and store only reference:

credential_reference = vault://...

Audit and logs must not contain secret values.

13. Tenant Isolation

If system is multi-tenant, tenant boundary is fundamental.

Fields:

tenant_id
customer_id
account_id
scope_id

Controls:

• tenant_id on owned rows,
• tenant-scoped unique constraints,
• tenant-aware queries,
• tenant-aware events,
• tenant-aware cache keys,
• tenant-aware search index,
• tenant-aware analytics partitions or row-level security,
• tenant boundary tests.

Failure mode:

Customer A sees Customer B quote due to missing tenant filter.

This is severe.

14. Row-Level and Field-Level Access

Access can be:

Data model should support scope and classification.

Example:

user_scope
- user_id
- scope_type = ACCOUNT
- scope_id
- role

Combined with field classification.

15. Purpose and Consent

Depending on legal/business requirements, data use may depend on purpose/consent.

Examples:

• contact may consent to billing email but not marketing,
• customer portal user may view only their site,
• usage data may be used for billing but not analytics without aggregation,
• contact data may be retained only while relationship active.

Model if applicable:

consent_record
- party_id
- consent_type
- purpose
- status
- effective_from
- effective_to
- source

Do not invent consent model if internally owned elsewhere, but know where it lives.

16. Data Access Audit

Access to sensitive data may need audit.

Examples:

• viewing invoice,
• viewing payment status,
• viewing margin/cost,
• exporting customer data,
• viewing full address/site access instruction,
• performing support impersonation,
• viewing approval evidence.

Access audit fields:

data_access_audit
- actor_id
- actor_type
- entity_type
- entity_id
- field_group
- access_type
- purpose
- decision
- occurred_at
- correlation_id

Do not audit every low-risk read if volume is excessive unless required. Focus on sensitive access.

17. Secure Event Design

Events should not leak sensitive data.

Bad event:

{
  "customerName": "John Doe",
  "billingAddress": "...",
  "paymentMethod": "4111111111111111",
  "margin": "30.00"
}

Better event:

{
  "customerId": "customer-id",
  "billingAccountId": "billing-account-id",
  "quoteId": "quote-id",
  "eventType": "QuoteAccepted"
}

Use references. Consumers can request sensitive details through authorized API if needed.

18. Secure Read Models and Analytics

Read models often copy data. Treat them as data products with their own security.

Questions:

• Does read model include PII?
• Does it include margin/cost?
• Does it include site coordinates?
• Does it include invoice/payment details?
• Who can query/export it?
• How is it refreshed/purged?
• Does masking carry over from source?

Analytics warehouse must not become uncontrolled copy of sensitive operational data.

19. Environment and Test Data

Production data should not be casually copied to lower environments.

Risks:

• PII leak in dev/test,
• billing data exposed,
• customer confidential data used by contractors,
• audit evidence visible to broad users.

Use:

• synthetic data,
• anonymization,
• pseudonymization,
• masking,
• tokenization,
• controlled refresh process,
• access logging.

Test data generation should preserve referential realism without leaking real secrets/PII.

20. Privacy by Design in Data Model

Privacy-by-design questions:

• Is this field necessary?
• Is it classified?
• Is access controlled?
• Is retention defined?
• Is it included in events?
• Is it copied into read model?
• Is it searchable/exportable?
• Is it encrypted or tokenized?
• Is deletion/anonymization possible?
• Is audit access controlled?

Model decisions should be recorded for sensitive fields.

21. PostgreSQL Physical Design

Classification metadata:

create table data_classification_rule (
  id uuid primary key,
  entity_type text not null,
  field_path text not null,
  classification text not null,
  sensitivity_level text not null,
  masking_policy text,
  encryption_required boolean not null default false,
  export_allowed boolean not null default true,
  event_publish_allowed boolean not null default true,
  retention_policy text,
  owner_group text,
  created_at timestamptz not null,
  updated_at timestamptz not null
);

Access audit:

create table data_access_audit (
  id uuid primary key,
  actor_type text not null,
  actor_id text not null,
  entity_type text not null,
  entity_id uuid,
  field_group text,
  access_type text not null,
  purpose text,
  decision text not null,
  source_system text,
  correlation_id text,
  occurred_at timestamptz not null,
  metadata jsonb
);

Consent record if applicable:

create table consent_record (
  id uuid primary key,
  party_id uuid not null,
  consent_type text not null,
  purpose text not null,
  status text not null,
  effective_from timestamptz not null,
  effective_to timestamptz,
  source_system text,
  captured_at timestamptz not null,
  evidence_reference text
);

Indexes:

create unique index uq_data_classification_field
on data_classification_rule (entity_type, field_path, classification);

create index idx_access_audit_actor_time
on data_access_audit (actor_id, occurred_at desc);

create index idx_access_audit_entity_time
on data_access_audit (entity_type, entity_id, occurred_at desc);

create index idx_consent_party_purpose
on consent_record (party_id, purpose, status, effective_from desc);

22. Java/JAX-RS Backend Implications

Security should be enforced at:

• authentication filter,
• authorization service,
• domain command service,
• DTO mapper,
• query projection,
• event publisher,
• audit writer.

Example DTO mapping:

QuoteResponse toResponse(Quote quote, Actor actor) {
    QuoteResponse dto = new QuoteResponse();
    dto.setId(quote.id());
    dto.setTotalAmount(quote.totalAmount());

    if (authorization.canView(actor, quote, Field.MARGIN)) {
        dto.setMarginAmount(quote.marginAmount());
    }

    return dto;
}

Do not expose field and rely on frontend to hide it.

23. API Contract Impact

API should document:

• which fields are sensitive,
• which permissions are required,
• masking behavior,
• whether field may be omitted due to authorization,
• export limitations,
• error behavior for forbidden data.

Example:

403 Forbidden

for entity-level access denial.

For field-level:

{
  "marginAmount": null,
  "fieldVisibility": {
    "marginAmount": "HIDDEN_BY_PERMISSION"
  }
}

or omit field based on API standard.

24. Cache and Search Impact

Sensitive data in cache/search is common risk.

Controls:

• do not cache restricted fields unless needed,
• include tenant/scope in cache key,
• purge cache on permission/classification change,
• secure Redis access,
• encrypt sensitive cache if needed,
• mask search index fields,
• restrict search facets that reveal sensitive data,
• avoid storing raw payload in DLQ/search tools.

Example failure:

User loses permission but cached response still shows margin.

Use short TTL or permission-versioned cache for sensitive responses.

25. Logging and Observability Impact

Logs must not contain:

• passwords/secrets/tokens,
• raw payment data,
• full tax ID,
• full address unless required,
• sensitive customer data,
• margin/cost,
• large raw payload with PII.

Use structured logging with redaction.

Correlation ID should be logged. Sensitive payload should not.

Error messages returned to clients should not expose internals or sensitive data.

26. Data Export

Exports are high-risk.

Examples:

• CSV quote export,
• invoice export,
• customer data export,
• product inventory export,
• audit export,
• analytics download.

Export model should include:

data_export_request
- id
- requested_by
- export_type
- scope
- status
- classification
- approval_required
- file_reference
- expires_at
- audit_reference

Controls:

• approval for sensitive export,
• scoped export,
• masking,
• watermarking if applicable,
• expiry,
• access audit,
• secure storage.

27. Security Data Quality Checks

Examples:

-- Classification missing for known sensitive entity fields
select *
from data_classification_rule
where entity_type = 'Quote'
  and field_path in ('marginAmount', 'costAmount');

-- Access audit denied spike
select actor_id, count(*)
from data_access_audit
where decision = 'DENIED'
  and occurred_at > now() - interval '1 day'
group by actor_id
order by count(*) desc;

-- Expired consent still active
select id, party_id, purpose
from consent_record
where status = 'ACTIVE'
  and effective_to is not null
  and effective_to < now();

Internal schema may differ.

28. Failure Modes

29. PR Review Checklist

When reviewing data model/API/event changes, ask:

• Is any field PII or sensitive?
• What classification applies?
• Who can view/update/export it?
• Is field-level access needed?
• Is masking required?
• Is encryption/tokenization required?
• Is this field copied to event/read model/cache/search?
• Is retention policy defined?
• Is audit access/change needed?
• Is this data needed at all?
• Is tenant/customer scope enforced?
• Are logs/errors redacted?
• Are lower environments protected?
• Are analytics exports controlled?
• Are tests covering unauthorized access and masking?

30. Internal Verification Checklist

Verify these in the internal CSG/team context:

• Existing data classification policy.
• Sensitive fields in quote/order/billing/product/service/resource inventory.
• Whether margin/cost/discount threshold are field-protected.
• Whether billing/payment data is tokenized/external-only.
• Whether address/site/location data has masking/access rules.
• Whether service/resource inventory has restricted views.
• Whether tenant/customer/account scope enforcement exists.
• Whether events are reviewed for sensitive payloads.
• Whether read models/search indexes copy sensitive fields.
• Whether audit logs contain PII or raw payloads.
• Whether data exports require approval/audit.
• Whether lower environments use masked/synthetic data.
• Whether consent/privacy data is owned internally or externally.
• Whether incidents mention data leak, overbroad access, sensitive event payload, or unmasked export.

31. Summary

Data security and privacy must be encoded in the data model.

A strong model must define:

• data classification,
• PII and sensitive commercial data,
• field-level access,
• row/tenant scope,
• masking,
• encryption/tokenization,
• secret references,
• secure event design,
• secure read models,
• access audit,
• consent/purpose if applicable,
• export governance,
• cache/search/log redaction,
• test data controls.

The key principle:

If sensitive data is not classified, scoped, masked, audited, and minimized at the model boundary, it will eventually leak through an API, event, dashboard, cache, log, or export.