Skip to content

Confidentiality

Confidentiality is the degree to which a system makes sure that only authorized parties can access its data. ISO/IEC 25010 uses this definition. NIST words it as sensitive information not being disclosed to unauthorized entities. (See ISO/IEC 25010 Product Quality Model and Security.)

How it differs from its neighbors. Confidentiality limits who can read data. Integrity limits who can change or delete it. Other security properties in ISO/IEC 25010 ask related questions:

  • Non-repudiation: actions can be proven to have happened, so nobody can deny them later.
  • Accountability: an action can be traced uniquely to the entity that did it.
  • Authenticity: an identity can be proven to be the one claimed.

The CIA triad. Azure guidance presents confidentiality, integrity and availability as interrelated principles, called the CIA triad. It applies them within a zero-trust approach. The STRIDE threat model pairs threats with controls. Information disclosure means someone sees data without permission, and confidentiality counters it. Spoofing maps to authentication, tampering to integrity, and repudiation to non-repudiation.

What teams do about it. Azure says confidentiality work should focus on three things:

  • access controls,
  • opacity (making data unreadable to outsiders),
  • an audit trail of activity on data and systems.

Data must also stay inside established trust boundaries. Segmentation helps. It limits sensitive flows to the roles and assets that need them.

Classify data first. Azure advises classifying data by type, sensitivity and risk, and giving each class a confidentiality level. That level guides the choice of encryption at rest, in transit and during processing. AWS gives example classes: public, internal, confidential and restricted. It suggests isolation boundaries per level. It also suggests tokenization or anonymization to lower the sensitivity of data. Encryption, access controls and auditing protect data at rest and in transit.

Legal driver. GDPR Article 32 lists the ongoing confidentiality, integrity, availability and resilience of processing systems as a security requirement. It names encryption and pseudonymisation as measures.

An online clinic stores patient notes, appointment times and a public price list. The team labels the notes “restricted”, the appointments “confidential” and the price list “public”. Notes get encryption and tight role-based access, with every read logged. The price list gets none of that. The notes live in a separate network segment that only the clinical application can reach.

Security and reliability can pull in opposite directions. Security-focused design can add points of failure and operational complexity. That affects availability: a locked-down system that breaks is not useful. Protecting all data equally does not solve this. AWS warns that uniform controls can over-protect low-sensitivity data and under-protect highly sensitive data. Classification lets you spend effort where it matters. (See Quality Attribute Trade-off.)

Sensitive data sits in its own zone. Only authorized access passes the trust boundary, and activity is logged.

Diagram source
flowchart LR
U[User] -->|authenticated, authorized| A[Application zone]
A -->|encrypted in transit| D[(Restricted data zone)]
X[Unauthorized party] -.->|blocked at trust boundary| D
D --> L[Audit trail]
  • Data is classified by type, sensitivity and risk, and each class has an assigned confidentiality level.
  • Encryption at rest and in transit is chosen based on the confidentiality level of the data.
  • Trust boundaries are defined, and sensitive flows are segmented so only roles and assets that need them can reach them.
  • An audit trail records activity on sensitive data and systems.
  • The document notes the trade-off between security measures and availability or operational complexity.