ISO/IEC 27001

⌘K
  1. Home
  2. Docs
  3. ISO/IEC 27001
  4. Other Doc
  5. Confidentiality Requirements Matrix

Confidentiality Requirements Matrix

1. Purpose

The Confidentiality Requirements Matrix defines the minimum confidentiality and information-protection requirements that apply to information based on its classification, sensitivity, business purpose, and method of use or sharing.

The matrix helps ensure that employees, contractors, suppliers, customers, partners, and other authorized parties understand how information must be accessed, stored, transferred, disclosed, retained, and securely disposed of.

Core Principle

Classify → Determine Requirements → Authorize Access → Protect → Share Securely → Monitor → Retain/Delete → Verify


2. Scope

This matrix applies to information handled by:

  • Employees
  • Contractors
  • Consultants
  • Interns
  • Temporary workers
  • Suppliers
  • Service providers
  • Partners
  • Customers
  • Auditors
  • Advisors
  • Other authorized third parties

It applies to information stored or processed in:

  • Laptops and desktops
  • Mobile devices
  • Cloud platforms
  • SaaS applications
  • Databases
  • Source-code repositories
  • Email
  • File-sharing platforms
  • Paper documents
  • Removable media
  • APIs
  • Production environments
  • Backup systems
  • Collaboration platforms

3. Information Classification Levels

The organization may use the following classification levels.

ClassificationGeneral DescriptionTypical Impact if Disclosed
PublicInformation approved for public disclosureLow
InternalInformation intended for internal business useLow/Medium
ConfidentialSensitive business, customer, technical, or operational informationMedium/High
RestrictedHighly sensitive information requiring enhanced protectionHigh/Critical

The organization’s approved Information Classification Policy should be the authoritative source for classification definitions.


4. Master Confidentiality Requirements Matrix

RequirementPublicInternalConfidentialRestricted
Authorized access requiredNoYesYesYes
Need-to-know principleRecommendedYesYesStrict
Named-user accessRecommendedYesYesMandatory where practical
Shared accountsGenerally acceptable only where appropriateAvoidProhibited unless specifically approvedProhibited except controlled emergency use
MFAWhere applicableWhere applicableRequired for sensitive systemsMandatory where technically applicable
Encryption in transitRecommendedRecommendedRequired for sensitive transfersRequired
Encryption at restNot normally requiredBased on riskRequired where appropriateRequired
Secure file transferNot normally requiredRecommendedRequiredRequired
External sharingPublicly permittedAuthorized recipientsExplicit authorizationExplicit approval
Third-party disclosurePermittedControlledContractual/authorizedFormal approval and contractual controls
Personal device storageGenerally permittedRestrictedOnly if approved and protectedNormally prohibited
Public cloud storagePermitted where intendedApproved servicesApproved services onlyApproved and specifically controlled
Public AI toolsPermitted for public informationOnly where approvedProhibited unless explicitly approvedProhibited unless formally approved
Source-code repositoriesPublic repositories where intentionally releasedPrivate repositoriesApproved private repositoriesHighly restricted repositories
Email sharingPermittedInternal/approved recipientsSecure transmission requiredAvoid where possible; approved secure channel
PrintingPermittedControlledRestrictedStrictly controlled
Physical storageNo special requirementControlledSecure storageLocked/controlled storage
LoggingNormally not requiredRisk-basedRequired for sensitive access where appropriateRequired
MonitoringNormally not requiredRisk-basedRequired where appropriateEnhanced monitoring
Data retentionBusiness needDefinedDefinedStrictly defined
Secure disposalNormal disposalControlled disposalSecure disposalSecure destruction/deletion
Incident reportingRequiredRequiredImmediate/priority reportingImmediate/priority reporting
NDA/confidentiality agreementNot normally requiredWhere appropriateNormally required for external partiesRequired
Access reviewNot normally requiredPeriodicPeriodicFrequent/risk-based
Data loss preventionNot normally requiredRisk-basedRecommended/required where appropriateRequired where appropriate
Regulatory restrictionsUsually lowMay applyMay applyFrequently applicable

5. Public Information Requirements

Definition

Information intentionally approved for public disclosure.

Examples:

  • Public website content
  • Published marketing material
  • Public documentation
  • Published job advertisements
  • Public press releases
  • Public product information

Minimum Requirements

☐ Information approved for public release

☐ No confidential information included

☐ No personal information unnecessarily exposed

☐ No credentials or security secrets included

☐ No internal architecture unnecessarily disclosed

☐ No restricted customer information included

Disclosure

Public information may be shared externally without additional confidentiality approval where it has been formally approved for public release.


6. Internal Information Requirements

Definition

Information intended primarily for authorized personnel within the organization.

Examples:

  • Internal procedures
  • Internal meeting notes
  • Internal operational information
  • Non-public employee communications
  • Internal project documentation
  • Internal process information

Requirements

☐ Authorized personnel access

☐ Appropriate authentication

☐ Approved storage locations

☐ Controlled external sharing

☐ Secure disposal

☐ No unnecessary public disclosure

External Disclosure

External disclosure should require appropriate authorization.


7. Confidential Information Requirements

Definition

Information that could cause meaningful business, security, privacy, financial, contractual, or reputational impact if improperly disclosed.

Examples:

  • Customer information
  • Supplier information
  • Business plans
  • Contracts
  • Pricing
  • Security assessments
  • VAPT reports
  • Product roadmaps
  • Technical architecture
  • Non-public source code
  • Internal audit reports

Requirements

☐ Need-to-know access

☐ Named user access where practical

☐ Strong authentication

☐ MFA for relevant systems

☐ Approved storage

☐ Encryption during sensitive transmission

☐ Encryption at rest where appropriate

☐ Controlled external sharing

☐ NDA/confidentiality requirements where applicable

☐ Secure disposal

☐ Security incident reporting

☐ Periodic access review


8. Restricted Information Requirements

Definition

Information where unauthorized access or disclosure could create significant or critical impact.

Examples:

  • Production credentials
  • Privileged credentials
  • Encryption keys
  • API secrets
  • Highly sensitive customer data
  • Sensitive personal data
  • Unreleased security vulnerabilities
  • Critical security architecture
  • Major incident investigation evidence
  • Highly sensitive intellectual property

Requirements

☐ Strict need-to-know access

☐ Individual named accounts

☐ MFA

☐ Privileged access controls

☐ Strong authentication

☐ Encryption

☐ Approved storage only

☐ Secure transfer

☐ Enhanced logging

☐ Access monitoring

☐ Periodic access review

☐ Formal authorization for external disclosure

☐ Secure deletion

☐ Incident escalation

☐ Evidence preservation where required


9. Access Control Matrix

Access RequirementPublicInternalConfidentialRestricted
General accessOpenAuthorized usersNeed-to-knowStrict need-to-know
Manager approvalNot normally requiredWhere appropriateRequired where applicableRequired
System owner approvalNoWhere appropriateRecommendedRequired
Privileged accessNot applicableLimitedRestrictedHighly restricted
Temporary accessNot normally requiredRecommended where appropriatePreferredRequired where practical
Access expiryNoRisk-basedRequired for temporary accessRequired
Periodic reviewNoPeriodicPeriodicFrequent/risk-based
Emergency accessNot applicableControlledControlledStrictly controlled and logged

10. Storage Requirements Matrix

Storage LocationPublicInternalConfidentialRestricted
Public websiteAllowedProhibited unless approvedProhibitedProhibited
Corporate file storageAllowedAllowedApproved locationApproved restricted location
Approved SaaSAllowedAllowedApproved servicesExplicitly approved services
Personal cloud storageGenerally unnecessaryRestrictedProhibited unless approvedProhibited
Local workstationAllowedAllowedProtectedRestricted
Removable mediaAllowedControlledRestrictedNormally prohibited
Source-code repositoryPublic if intentionally publicPrivatePrivate restrictedHighly restricted
BackupAs applicableRequired where appropriateProtectedStrongly protected

11. Information Transfer Matrix

Transfer MethodPublicInternalConfidentialRestricted
Public websiteYesNoNoNo
Normal emailYesControlledAvoid unless protectedAvoid
Encrypted emailYesYesYesWhere approved
Approved file sharingYesYesYesYes, if authorized
Secure APIYesYesYesYes
Public file-sharing linkYesNoNoNo
Encrypted transferOptionalRecommendedRequiredRequired
Physical deliveryOptionalControlledSecure deliverySecure tracked delivery

12. Third-Party Disclosure Matrix

RequirementPublicInternalConfidentialRestricted
External disclosureAllowed if approved for public releaseAuthorization requiredFormal authorizationFormal approval
NDAUsually unnecessaryWhere appropriateNormally requiredRequired
Security reviewNoRisk-basedRecommendedRequired where appropriate
Supplier assessmentNoRisk-basedRequired for relevant suppliersRequired
Data-processing agreementNoIf personal data appliesIf personal data appliesRequired where applicable
Subprocessor reviewNoWhere applicableRequired where applicableRequired
Disclosure loggingNot normally requiredRisk-basedRecommendedRequired where appropriate

13. Customer Information Requirements

Where customer information is classified as Confidential or Restricted:

☐ Customer requirements identified

☐ Contractual confidentiality requirements reviewed

☐ Customer data minimized

☐ Access restricted

☐ Approved storage used

☐ Secure transfer used

☐ Encryption considered/implemented

☐ Retention defined

☐ Deletion/return requirements defined

☐ Incident notification requirements understood

☐ Subprocessor requirements considered


14. Personal Data Requirements

Where personal data is involved:

☐ Processing purpose identified

☐ Data minimization applied

☐ Access restricted

☐ Appropriate security controls implemented

☐ Retention defined

☐ Secure deletion defined

☐ External disclosure controlled

☐ Applicable privacy requirements identified

☐ International transfer requirements assessed where applicable

☐ Data-processing agreement completed where required


15. Security Credentials and Secrets

The following should normally be treated as Restricted:

  • Passwords
  • API keys
  • Access tokens
  • SSH private keys
  • Cloud credentials
  • Encryption keys
  • Database credentials
  • Signing keys
  • Certificates containing private keys
  • Break-glass credentials

Requirements

☐ Named access where possible

☐ MFA

☐ Secure secrets storage

☐ No storage in source code

☐ No sharing through unsecured channels

☐ Rotation

☐ Revocation

☐ Access logging

☐ Compromise response


16. Source Code Requirements

Non-public source code should normally be classified as Confidential or Restricted, depending on business impact.

Requirements

☐ Private repository

☐ Named users

☐ Need-to-know access

☐ MFA

☐ Branch/repository protection

☐ Access review

☐ No unauthorized copying

☐ No upload to public repositories

☐ No submission to unapproved AI services

☐ Secure backup

☐ Access revocation during offboarding


17. Security Vulnerability Information

Information relating to vulnerabilities should receive enhanced protection.

Examples:

  • VAPT findings
  • Exploit details
  • Security weaknesses
  • Unpatched vulnerabilities
  • Penetration-test reports
  • Security incident investigation details

Requirements

☐ Restricted access

☐ Need-to-know

☐ Secure storage

☐ Secure transfer

☐ Controlled external disclosure

☐ Appropriate remediation tracking

☐ No public disclosure before authorization


18. AI and Generative AI Requirements

Before entering information into an AI or external processing service, determine:

QuestionRequirement
Is the information Public?Generally permitted subject to policy
Is it Internal?Use only approved services
Is it Confidential?Explicit approval may be required
Is it Restricted?Normally prohibited unless specifically authorized
Is personal data involved?Privacy/legal assessment required
Is customer data involved?Customer/contractual requirements must be considered
Is source code involved?Approved AI service required
Is security information involved?Enhanced approval required

Prohibited Practice

Do not paste passwords, API keys, customer data, private source code, or sensitive security findings into an unapproved public AI service.


19. Remote Work Requirements

For Confidential and Restricted information:

☐ Authorized devices only

☐ Strong authentication

☐ MFA where applicable

☐ Device encryption

☐ Secure network access

☐ Screen/privacy protection

☐ No unauthorized family/shared access

☐ Approved cloud storage

☐ Secure physical handling

☐ Secure disposal


20. Printing Requirements

ClassificationPrinting Requirement
PublicNo special restriction
InternalControlled where appropriate
ConfidentialMinimize printing; secure storage
RestrictedPrinting only when necessary and authorized

Printed Confidential or Restricted information should not be left unattended.


21. Retention and Disposal Matrix

RequirementPublicInternalConfidentialRestricted
Retention based on business needRecommendedYesYesStrictly defined
Retention scheduleOptionalRecommendedRequired where applicableRequired
Normal disposalYesControlledSecure disposalSecure destruction/deletion
Data deletion verificationNoRisk-basedWhere requiredWhere appropriate
Legal hold considerationYesYesYesYes

22. Security Incident Requirements

Any suspected unauthorized disclosure should be reported through the organization’s incident-management process.

Examples

  • Wrong recipient received an email;
  • Confidential document sent to an unauthorized person;
  • Laptop containing Restricted information was lost;
  • Customer data was uploaded to an unapproved service;
  • Source code was exposed publicly;
  • Credentials were accidentally disclosed;
  • Confidential information was shared with an unauthorized supplier.

Required Actions

Report → Contain → Assess → Preserve Evidence → Notify → Remediate → Record → Review


23. Third-Party Confidentiality Requirements

Before providing Confidential or Restricted information to an external party:

☐ Business need identified

☐ Third party identified

☐ Information classified

☐ Access scope defined

☐ NDA/confidentiality agreement reviewed

☐ Security requirements defined

☐ Personal-data requirements assessed

☐ Supplier risk assessed where applicable

☐ Secure transfer method defined

☐ Retention/deletion requirements defined

☐ Incident notification requirements defined


24. Contractual Requirements

Contracts involving Confidential or Restricted information should address relevant requirements such as:

  • Confidentiality
  • Information security
  • Access control
  • Data protection
  • Incident notification
  • Subprocessors
  • Data location
  • Data retention
  • Data deletion
  • Return of information
  • Security assurance
  • Audit rights where appropriate
  • Business continuity
  • Termination
  • Exit requirements

25. Evidence Requirements

The organization should retain appropriate evidence demonstrating that confidentiality requirements are implemented.

Examples:

☐ Classification records

☐ Access approvals

☐ Access review records

☐ NDA records

☐ Supplier agreements

☐ Data-processing agreements

☐ Secure transfer records

☐ Security assessment records

☐ Incident records

☐ Deletion confirmations

☐ Offboarding records

☐ Security training records

☐ Policy acknowledgements

☐ Exception approvals

Evidence should not unnecessarily contain passwords, API keys, private keys, or other secrets.


26. Responsibility Matrix

ActivityInformation OwnerIT/SecurityEmployee/UserSupplier
ClassificationA/RCCC
Access approvalA/RCIC
Access provisioningIA/RIC
Secure handlingACRR
Secure transferAC/RRR
External disclosureA/RCIC
Incident reportingARRR
RetentionA/RCIC
Secure disposalARRR
Periodic reviewA/RRCC

R = Responsible
A = Accountable
C = Consulted
I = Informed


27. Exception Management

Where the standard confidentiality requirements cannot be implemented:

  1. Document the exception.
  2. Identify the reason.
  3. Assess the risk.
  4. Define compensating controls.
  5. Obtain appropriate approval.
  6. Define an expiry/review date.
  7. Record the exception.

Exception Record

FieldDetails
Exception ID
Information
Classification
Requirement
Reason
Risk
Compensating Control
Owner
Approver
Expiry/Review Date
Status

28. AWS SaaS Startup Example

An AWS SaaS startup classifies the following information:

InformationClassificationKey Requirements
Public website contentPublicApproved for public release
Internal sprint planInternalAuthorized internal access
Customer contractConfidentialNeed-to-know, secure storage
VAPT reportRestrictedStrict access, secure transfer
AWS architectureConfidentialRestricted access, approved sharing
Production database credentialsRestrictedSecrets manager, MFA, logging
API keyRestrictedSecure storage, rotation
Public API documentationPublicApproved publication
Customer personal dataConfidential/RestrictedPrivacy + access controls
Source codeConfidential/RestrictedPrivate repository, MFA
Security incident evidenceRestrictedStrict access, evidence preservation

Practical Example

A developer needs to share an AWS architecture diagram with a VAPT provider.

The process should be:

Classify → Verify Provider → NDA → Approve Access → Secure Transfer → Limit Access → Review → Revoke/Return

The diagram should not simply be attached to an unrestricted email or uploaded to a public file-sharing service.


29. Startup-Friendly Implementation Model

A startup does not need a complicated confidentiality framework.

Start with four clear rules:

Rule 1 — Classify

Every important information asset should have a classification.

Rule 2 — Restrict

Confidential and Restricted information should only be accessible to people who need it.

Rule 3 — Protect

Use appropriate authentication, encryption, secure storage, and secure transfer.

Rule 4 — Close

When access or business need ends, remove access and return/delete information as required.

Startup Minimum Controls

☐ Information classification policy

☐ Confidentiality/NDA requirements

☐ Access control

☐ MFA

☐ Approved cloud storage

☐ Secure file sharing

☐ Secure secrets management

☐ Employee/contractor offboarding

☐ Supplier confidentiality requirements

☐ Incident reporting

☐ Secure disposal


30. Common Mistakes

Avoid:

  • Treating all information as equally sensitive.
  • Marking everything “Confidential” without defining handling requirements.
  • Granting access based on convenience.
  • Sharing customer data when test data would be sufficient.
  • Sending Restricted information through normal email.
  • Storing credentials in documents or source code.
  • Uploading confidential information to public AI tools.
  • Allowing suppliers unrestricted access.
  • Forgetting to revoke access after a project ends.
  • Keeping confidential information indefinitely.
  • Failing to document exceptions.
  • Assuming an NDA alone protects information.
  • Keeping audit evidence that contains actual passwords or secrets.

31. Relationship With Other ISMS Documents

DocumentRelationship
Information Classification PolicyDefines classification principles
Information Classification RegisterRecords classified information
Confidentiality and NDA PolicyDefines confidentiality obligations
Employee NDAProtects employee-handled information
Contractor NDAProtects contractor-handled information
Supplier Confidentiality AgreementProtects supplier-shared information
Access Management ProcedureControls access
Information Transfer ProcedureControls information exchange
Data Retention PolicyDefines retention requirements
Secure Disposal ProcedureDefines secure destruction
Incident Response ProcedureHandles unauthorized disclosure
Supplier Security RequirementsDefines third-party protection
Employee Offboarding PolicySupports access and information protection at exit
Data Processing AgreementAddresses personal-data processing

32. ISO 27001 / SOC 2 Connection

The Confidentiality Requirements Matrix supports the organization’s broader information-security framework by translating information classification into practical protection requirements.

It can provide evidence that the organization has considered:

  • Information classification;
  • Access control;
  • Need-to-know;
  • Information transfer;
  • Confidentiality obligations;
  • Supplier/third-party protection;
  • Secure disposal;
  • Incident management;
  • Data protection;
  • Security monitoring.

The matrix itself is not a substitute for the organization’s risk assessment, policies, procedures, or applicable ISO 27001/SOC 2 controls.

The organization should determine the controls and requirements appropriate to its specific risks, services, information, contractual obligations, and regulatory environment.


33. Quick Audit Checklist

☐ Information classification defined

☐ Classification levels approved

☐ Confidentiality requirements documented

☐ Access requirements defined

☐ Need-to-know implemented

☐ MFA requirements defined

☐ Encryption requirements defined

☐ Secure transfer requirements defined

☐ Third-party disclosure requirements defined

☐ NDA requirements defined

☐ Customer data requirements defined

☐ Personal-data requirements defined

☐ AI/external-service requirements defined

☐ Source-code requirements defined

☐ Credential/secret requirements defined

☐ Retention requirements defined

☐ Secure disposal requirements defined

☐ Incident reporting defined

☐ Exception process defined

☐ Evidence requirements defined

☐ Periodic review established


34. Document Control

FieldDetails
Document NameConfidentiality Requirements Matrix
Document Owner
Version
Effective Date
Review Frequency
Approved By
ClassificationInternal
Next Review Date
StatusDraft / Approved / Retired

35. Final Audit Trail

For every significant category of information, the organization should be able to demonstrate:

What information is it?
How is it classified?
Who owns it?
Who can access it?
Why do they need access?
Where can it be stored?
How can it be transferred?
Can it be shared with third parties?
What contractual requirements apply?
Can it be processed using AI or external services?
How long should it be retained?
How should it be deleted or destroyed?
What happens if it is disclosed accidentally?
What evidence demonstrates that the requirements were followed?

Final Principle

Classification has value only when it changes how information is handled. The Confidentiality Requirements Matrix converts labels such as Public, Internal, Confidential, and Restricted into clear, measurable security requirements that users and third parties can actually follow.