Data Security and Privacy

Data security protects data against unauthorised access, alteration, loss and disruption. Data privacy governs whether data about people is collected, used, shared, retained and exposed appropriately for a legitimate purpose.

Security asks whether data is protected. Privacy asks whether the organisation should be doing this with the data in the first place.

The two disciplines overlap but are not interchangeable. A dataset can be encrypted, access-controlled and backed up—and still be collected unnecessarily, retained too long or reused for a purpose that was never justified. Conversely, a legitimate purpose can still be undermined by weak security.

ARTICLE ID: DATA.MANAGEMENT.010
Canonical function: protection, legitimate use and exposure control
Series route: What Is Data Management? → Data Governance → Data Security and Privacy.

The Three Classical Security Objectives

• Confidentiality: prevent unauthorised disclosure.
• Integrity: prevent or detect unauthorised or accidental alteration.
• Availability: ensure legitimate users can access data when required.

These objectives interact. Extreme confidentiality that makes critical data unavailable can fail the organisation. Extreme availability without access control can expose sensitive information. Security is therefore a controlled balance, not one absolute property.

Privacy Begins with Purpose

Before collecting personal data, an organisation should be able to explain why the data is needed, how it will be used, who needs access, how long it should remain and what consequence could arise from misuse or exposure.

A strong privacy question is:

If this field disappeared, would the service or legitimate purpose materially fail?

If the answer is no, the organisation should examine whether collection is necessary at all.

Data Minimisation

Data minimisation means limiting collection, access and retention to what is needed for a defined purpose. It reduces privacy exposure, security impact, storage cost and governance burden simultaneously.

More data is not automatically more capability. Unnecessary data can become unnecessary liability.

Identity and Authentication

Security begins with knowing who or what is requesting access. Authentication establishes identity through credentials, cryptographic keys, devices, multi-factor methods or other mechanisms.

Weak authentication undermines every downstream access rule. A system cannot enforce permissions reliably if it cannot establish identity reliably.

Authorisation

Authorisation determines what an authenticated identity may do. Good access design follows least privilege: grant only the access required for the role and purpose, and remove it when no longer needed.

Useful access dimensions include:

• dataset;
• field;
• row or record;
• operation: read, write, export, delete;
• time window;
• device or network context;
• purpose or workflow state.

Role-Based and Attribute-Based Access

Role-based access control assigns permissions according to organisational roles. Attribute-based access control can use additional context such as department, data sensitivity, location, purpose or device state.

The goal is not maximum complexity. It is enough precision to align access with legitimate need.

Encryption

Encryption protects data by converting it into a form that requires authorised keys to recover. Common control points include data in transit and data at rest.

Encryption is powerful but not magical. If an authorised application account is compromised, an attacker may access decrypted data through the application. Key management, identity and monitoring remain essential.

Key Management

Encryption depends on keys. Key management covers creation, storage, rotation, access, revocation and recovery. Poor key management can make strong cryptography operationally weak.

A useful principle is separation of duties: the same pathway should not automatically control data, keys and audit evidence without independent oversight where consequence is high.

Integrity Controls

Integrity controls help detect or prevent unauthorised changes. They can include database constraints, hashes, digital signatures, append-only logs, checksums, version control and reconciliation.

Integrity is especially important for records used as evidence. A file surviving is not enough; the organisation may also need confidence that it has not been silently altered.

Availability and Resilience

Security includes keeping legitimate services available. Ransomware, accidental deletion, system failure, misconfiguration and vendor outages can all make data inaccessible.

Availability therefore connects security with Data Backup, Recovery and Resilience.

Logging and Audit Trails

Audit trails record important access, changes and administrative actions. They help answer:

• who accessed the data;
• when;
• from where;
• what action occurred;
• which record changed;
• which privileged action was performed;
• whether access patterns are unusual.

Logging should itself be protected. An attacker who can erase the evidence of access weakens accountability.

Security Monitoring

Monitoring looks for unusual access, excessive downloads, impossible travel, repeated authentication failure, unexpected privilege changes, anomalous queries and other signals.

Detection is not proof of malicious behaviour. It is a routing mechanism for investigation.

The Insider Risk Problem

Not every data incident comes from an external attacker. Employees, contractors and privileged administrators may make mistakes, misuse access or have accounts compromised.

Controls should therefore assume that internal access is not automatically safe. Least privilege, logging, segregation of duties and periodic access review remain important inside trusted networks.

Access Creep

Access creep occurs when people accumulate permissions as roles change but old permissions are never removed. Over years, a user can end up with far more access than current work requires.

Regular access recertification and automated role changes help keep current authority aligned with current need.

Pseudonymisation and De-Identification

Reducing direct identifiers can lower privacy risk for analysis and research. Techniques may include replacing identifiers, generalising values or separating identity from analytical attributes.

But de-identification is not absolute. Combining datasets can sometimes re-identify individuals from indirect patterns. Risk should therefore be assessed in the actual data environment, not only from the absence of names.

Aggregation

Aggregation can reduce exposure by reporting groups rather than individuals. Yet very small groups or rare characteristics can still reveal identity.

Privacy controls should consider what the receiver can infer, not only what fields are directly shown.

Data Sharing

Sharing creates a new privacy and security boundary. Before transferring data, organisations should define the recipient, purpose, scope, safeguards, retention expectations, onward-sharing rules and incident responsibilities.

See Data Integration and Interoperability.

Third-Party and Cloud Risk

Using a service provider does not make data-governance responsibility disappear. Organisations should understand where data is processed, who can access it, how incidents are handled, how backups work, how deletion is performed and what happens when the service relationship ends.

Contractual controls and technical controls should reinforce each other.

Privacy Across the Lifecycle

Privacy is not a one-time approval. Different risks appear at different lifecycle stages:

• collection: excessive or unclear capture;
• storage: exposure and weak access control;
• use: purpose drift and inappropriate inference;
• sharing: loss of control over recipients;
• analytics: re-identification and unexpected profiling;
• retention: keeping personal data after purpose ends;
• disposal: incomplete deletion across copies and backups.

See The Data Lifecycle.

Privacy by Design

Privacy by design means treating privacy requirements as architectural inputs rather than late-stage compliance checks.

Examples include:

• collecting fewer fields;
• separating identity from analysis;
• using shorter default retention;
• restricting export;
• limiting administrative access;
• preserving consent or purpose metadata where relevant;
• making deletion technically possible.

Singapore Context

In Singapore, organisations handling personal data should work from the current requirements and guidance of the Personal Data Protection Commission under the Personal Data Protection Act. Data-management design should align collection, use, disclosure, protection, accuracy where material, retention and accountability with applicable obligations.

This article is educational and does not replace legal advice or current regulatory guidance for a specific organisation.

Security Classification

Classification helps match controls to consequence. An organisation may distinguish public, internal, confidential or highly restricted information, though labels and rules vary.

A classification is useful only when it changes behaviour: who can access, where data can be stored, whether it can be exported, how it must be encrypted and how incidents are handled.

Secrets Are Data Too

Passwords, API keys, tokens and private keys are themselves sensitive data. They should not be embedded casually in code, spreadsheets, notebooks or logs.

Secret-management systems, rotation and scoped credentials reduce the damage of accidental exposure.

Secure Deletion

Deleting a visible record may not remove every copy. Data can persist in backups, logs, caches, exports, replicas and downstream systems.

Deletion therefore requires lineage and lifecycle awareness. The organisation should know where data travelled and which copies have independent retention obligations.

Incident Response

Security incidents should follow a controlled route:

Detect → Contain → Preserve Evidence → Assess Scope → Eradicate Cause → Recover → Notify Where Required → Review → Improve

Data lineage helps determine what was exposed. Audit logs help determine what occurred. Backups support recovery. Governance determines who decides and who communicates.

Ransomware

Ransomware illustrates why security and resilience cannot be separated. Attackers may encrypt systems, steal data, destroy backups or threaten disclosure.

Defence therefore needs more than endpoint protection: privileged-access control, segmentation, immutable or isolated backups, monitoring, recovery testing and incident preparation all matter.

AI and Data Security

AI systems create new data flows. Prompts, retrieved documents, model outputs, evaluation data and feedback logs may contain sensitive information. Security should cover the full AI pipeline rather than only the underlying model.

Important questions include:

• Can sensitive data enter prompts?
• Which users can retrieve restricted documents?
• Are logs retained unnecessarily?
• Can model outputs expose source data?
• Which external providers process the data?
• How are access rights carried into retrieval?

AI and Privacy

AI can combine and infer information in ways that were not obvious when data was collected. Privacy review should therefore consider both direct fields and derived inferences.

A model that predicts a sensitive characteristic can create privacy impact even if the sensitive field was never stored explicitly.

Education Example

A learning organisation may hold names, contact details, attendance, assessment and communications. Good design separates educational need from curiosity. Teachers may need learning evidence but not billing data. Finance staff may need payment status but not detailed academic notes.

Purpose-based access protects the learner by reducing unnecessary visibility across roles.

Security Anti-Patterns

• Shared admin accounts: actions cannot be attributed reliably.
• Permanent privilege: temporary access never expires.
• Encryption-only thinking: keys, identities and applications remain weak.
• Internal equals trusted: insider and compromised-account risk is ignored.
• Backup without isolation: attackers can destroy recovery copies too.
• Logging without review: evidence exists but nobody watches it.
• Secrets in code: credentials spread through repositories and copies.

Privacy Anti-Patterns

• Collect everything: future possibility becomes the only purpose.
• Purpose drift: old data is quietly reused for a new goal.
• Retention by inertia: information remains because storage is cheap.
• Consent as universal answer: broader governance questions are ignored.
• De-identified therefore safe: re-identification and linkage risk are dismissed.
• Security equals privacy: legitimate-use questions are never asked.

A Practical Security and Privacy Checklist

1. What is the legitimate purpose?
2. Which data is actually necessary?
3. What is the sensitivity and consequence of exposure?
4. Who needs access?
5. How is identity established?
6. How is least privilege enforced?
7. How is data protected in transit and at rest?
8. How are keys and secrets controlled?
9. Which important actions are logged?
10. How are unusual access patterns detected?
11. Where has the data been copied or shared?
12. What retention rule applies?
13. Can deletion be performed across the known route?
14. Can the organisation recover after loss or attack?
15. Who owns incident decisions and escalation?

A Maturity Ladder

1. Protected: basic authentication, permissions and backup exist.
2. Classified: sensitivity guides controls.
3. Least-privileged: access follows current role and need.
4. Observable: important access and anomalies are monitored.
5. Purpose-aware: privacy and minimisation shape collection and use.
6. Lifecycle-aware: sharing, retention and disposal are controlled.
7. Resilient: recovery survives attack and operational failure.
8. Adaptive: incidents, new uses and changing risks improve the system.

The Deeper Principle: Protect the Person and the Evidence

Security and privacy are often framed as constraints on data use. A better view is that they make durable, legitimate use possible.

Security protects the evidence from unauthorised change, loss and disclosure. Privacy protects people from unjustified exposure and use. Together they preserve the trust required for data to remain useful across time.

Data Management Series

• What Is Data Management?
• Data Governance
• The Data Lifecycle
• Data Security and Privacy
• Data Backup, Recovery and Resilience

Further Reading

• Personal Data Protection Commission Singapore — Personal Data Protection Act
• NIST Privacy Framework
• NIST Cybersecurity Framework

---

Final idea: secure and private data management does not ask only whether information can be used. It asks whether the right data is being used by the right receiver, for the right purpose, under controls strong enough to protect both the evidence and the people represented by it.