Document Information

Field	Details
Document Title	[Enter Document Title]
Document ID	[DOC-XXX-000]
Document Type	[Security Report / Assessment / Procedure / Technical Document / Other]
Information Classification	RESTRICTED
Information Owner	[Name / Role]
Document Owner	[Name / Role]
Department	[Department]
Version	[Version]
Effective Date	[DD-MMM-YYYY]
Review Date	[DD-MMM-YYYY]
Status	[Draft / Approved / Superseded / Retired]
Approved By	[Name / Role]

---

RESTRICTED INFORMATION NOTICE

RESTRICTED – STRICTLY LIMITED ACCESS

This document contains highly sensitive information belonging to [Organization Name].

Access is restricted to specifically authorized individuals with a legitimate business requirement.

Unauthorized access, copying, disclosure, distribution, modification, extraction, or use is prohibited.

Do not forward, upload, reproduce, or disclose this document without explicit authorization from the Information Owner.

If this document has been received incorrectly, immediately notify [Security Team / Document Owner] and follow the organization’s incident reporting process.

---

1. Purpose

This document contains restricted information relating to:

[Describe the purpose and nature of the information.]

Examples:

• Production security architecture
• Critical vulnerability assessment
• Penetration-testing report
• Security incident investigation
• Encryption/key-management information
• Privileged access information
• Sensitive customer information
• Critical infrastructure configuration
• Highly sensitive business information

---

2. Scope

This document applies to:

• [System/Application]
• [Business Process]
• [Project]
• [Environment]
• [Department]
• [Authorized Personnel]
• [Third Parties, if applicable]

---

3. Classification

Classification: RESTRICTED

Restricted information is information for which unauthorized disclosure, modification, loss, or access could result in significant security, financial, legal, regulatory, contractual, operational, privacy, or reputational impact.

Examples may include:

• Passwords and authentication secrets
• API keys and access tokens
• Private encryption keys
• Production credentials
• Highly sensitive vulnerability information
• Security incident investigation records
• Critical security architecture
• Sensitive customer information
• Highly sensitive employee information
• Critical infrastructure information
• Confidential security configurations
• Sensitive business strategy or transaction information

The organization should define the exact criteria for Restricted classification through its Information Classification Policy and risk assessment.

---

4. Authorized Access

Access must be limited to specifically authorized individuals.

Role	Access Level	Approval Required
Information Owner	Full	No
Security Lead	As Required	Owner
System Owner	As Required	Owner
IT/Cloud Administrator	Minimum Required	Owner/Security
Internal Auditor	As Required	Owner
External Auditor	Specific Scope Only	Formal Approval
Contractor	Exceptional / Need-to-Know	Formal Approval
General Employees	No Access	N/A

Access should follow:

Need-to-Know + Least Privilege + Explicit Authorization

---

5. Access Approval

Before access is granted, record:

Field	Details
Requestor	[Name]
Role	[Role]
Business Need	[Reason]
Information Required	[Description]
Access Level	[Read / Edit / Admin]
Access Start Date	[Date]
Access Expiry Date	[Date]
Approved By	[Name / Role]
Security Review	[Required / Not Required]
Status	[Approved / Rejected / Expired]

Access should have an expiry date where permanent access is not required.

---

6. Storage Requirements

Restricted information must be stored only in specifically approved and appropriately secured locations.

Examples:

• Approved restricted-access document repository
• Enterprise GRC platform
• Approved encrypted storage
• Approved secrets-management platform
• Approved security-management platform
• Approved restricted cloud storage

Do not store Restricted information in:

• Personal email
• Personal cloud storage
• Public repositories
• Public file-sharing services
• Unapproved SaaS platforms
• Unapproved AI tools
• Personal messaging applications
• Unencrypted removable media

---

7. Encryption

Restricted information should be protected using appropriate encryption.

Where applicable:

• Encrypt data at rest.
• Encrypt data in transit.
• Use approved cryptographic mechanisms.
• Protect encryption keys separately.
• Restrict key-management access.
• Rotate keys where required.
• Maintain appropriate key-management records.

Important: Encryption keys, private keys, passwords, and credentials should not be stored together with the information they protect unless specifically designed and secured for that purpose.

---

8. Access Authentication

Access to Restricted information should use strong authentication appropriate to the risk.

Controls may include:

• Individual user accounts
• MFA
• Strong authentication
• Privileged access management
• Role-based access
• Conditional access
• Device security controls
• Session controls
• Access logging

Shared accounts should be avoided unless there is a documented technical or business requirement and appropriate compensating controls.

---

9. Copying and Downloading

Copying or downloading Restricted information should be minimized.

Before making a copy:

• Confirm the business requirement.
• Confirm authorization.
• Use an approved location.
• Apply equivalent or stronger security controls.
• Record the copy where required.

Local copies should be removed when no longer required.

---

10. External Sharing

External sharing of Restricted information requires explicit approval.

Before sharing:

1. Identify the recipient.
2. Verify the recipient’s identity.
3. Confirm the business requirement.
4. Confirm contractual requirements.
5. Confirm legal/privacy requirements.
6. Obtain Information Owner approval.
7. Use an approved secure transfer method.
8. Apply encryption where required.
9. Define access expiry where possible.
10. Record the transfer.

External recipients should receive only the minimum information required.

---

11. Restricted Document Link

Where the document is maintained electronically:

Restricted Document Repository:
[Insert Restricted Document Link]

Access: Authorized personnel only

Link Expiry: [Date / Not Applicable]

Owner: [Name / Role]

Access Review: [Date]

Do not place restricted documents in publicly accessible URLs or repositories.

---

12. Email Handling

Restricted information should generally not be transmitted through ordinary email attachments unless specifically authorized and appropriately protected.

Where email transmission is necessary:

• Verify recipients.
• Verify CC/BCC recipients.
• Use approved corporate email.
• Use encryption or protected attachments where required.
• Use a separate secure mechanism for passwords.
• Avoid unnecessary forwarding.

---

13. Messaging and Collaboration Tools

Restricted information must not be posted in:

• Public chat channels
• General-purpose collaboration spaces
• Unapproved messaging applications
• Public forums
• Social media
• Unapproved AI tools

Where collaboration is necessary, use an approved restricted-access workspace.

---

14. AI and Generative AI

Restricted information must not be entered into public or unapproved AI services.

This includes:

• Production credentials
• API keys
• Private keys
• Security incident details
• Critical vulnerabilities
• Penetration-testing findings
• Customer restricted information
• Production database extracts
• Security architecture
• Sensitive source code
• Confidential investigation information

AI use involving Restricted information requires explicit organizational approval and an approved tool/use case.

---

15. Production Environment Information

Information relating to production systems should be handled carefully where it could enable unauthorized access or compromise.

Examples include:

• Production architecture
• Administrative interfaces
• Privileged roles
• Network configurations
• Security configurations
• Firewall rules
• Secrets
• Database connection details
• Infrastructure credentials
• Sensitive monitoring information

Production information should be shared only with personnel who require it for their authorized responsibilities.

---

16. Credentials and Secrets

Credentials and secrets should normally be managed through approved security mechanisms rather than included directly in ordinary documents.

Examples:

• Passwords
• API keys
• Access tokens
• SSH private keys
• Cloud credentials
• Database passwords
• Encryption keys
• Certificates/private keys

Use approved mechanisms such as:

• Enterprise password manager
• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager
• Approved privileged access management platform

Never place production secrets in:

• Public source repositories
• Ordinary spreadsheets
• Email
• Chat messages
• Ticket descriptions
• Unapproved documents

---

17. Restricted Security Reports

Security reports such as:

• Vulnerability assessment reports
• Penetration-testing reports
• Red-team reports
• Incident investigation reports
• Security architecture reviews

should be distributed only to authorized recipients.

Where appropriate, reports should distinguish between:

• Executive-level findings
• Technical findings
• Exploitation details
• Credentials/secrets
• Remediation information

Highly sensitive technical exploitation details may require additional access restrictions.

---

18. Physical Handling

Printed Restricted documents should be avoided unless necessary.

Where printing is required:

• Use authorized printers.
• Collect immediately.
• Do not leave unattended.
• Store in a locked location.
• Maintain distribution records where required.
• Do not leave documents in meeting rooms.
• Securely destroy when no longer required.

---

19. Remote Working

Restricted information should only be accessed remotely where specifically authorized.

Users must:

• Use an approved device.
• Use strong authentication/MFA.
• Prevent unauthorized persons from viewing information.
• Use approved remote-access mechanisms.
• Avoid public computers.
• Protect the physical device.
• Follow the Remote Working Policy.

---

20. Mobile and Personal Devices

Restricted information should not be stored on personal devices unless explicitly authorized and appropriate technical controls are implemented.

Where authorized:

• Device encryption should be enabled.
• Strong authentication must be used.
• Organizational access must be controlled.
• Remote wipe should be available where appropriate.
• Access should be removable when no longer required.

---

21. Third-Party Access

Third-party access to Restricted information requires formal authorization.

Before access:

• Identify the business requirement.
• Assess supplier risk.
• Review contractual requirements.
• Confirm confidentiality obligations.
• Define access scope.
• Define access duration.
• Apply least privilege.
• Establish monitoring requirements.
• Define information return/deletion requirements.

Third-party access should be revoked when the business requirement ends.

---

22. Access Monitoring

Access to Restricted information should be logged and monitored where technically and operationally appropriate.

Logs may include:

• User identity
• Date/time
• Source
• Resource accessed
• Activity performed
• Download/export activity
• Administrative actions
• Failed access attempts

Security teams should investigate suspicious or unauthorized activity.

---

23. Access Review

Access should be reviewed periodically and whenever a significant change occurs.

Review triggers include:

• Employee transfer
• Employee termination
• Contractor termination
• Role change
• Project completion
• Change of system ownership
• Security incident
• Change in information sensitivity
• Change in business requirement

Example:

Monthly: Highly privileged access
Quarterly: Restricted document access
Immediately: Termination or suspected compromise

These frequencies are organizational examples and should be determined based on risk.

---

24. Data Retention

Restricted information should be retained only for as long as necessary.

Retention should consider:

• Business requirements
• Legal requirements
• Regulatory requirements
• Customer contracts
• Security requirements
• Audit requirements
• Investigation requirements

Retention period:

[Insert Period]

Retention Owner:

[Name / Role]

---

25. Secure Disposal

When retention requirements have been satisfied, Restricted information must be securely disposed of.

Depending on the medium:

• Secure deletion
• Cryptographic erasure
• Secure shredding
• Media destruction
• Secure cloud deletion
• Removal from approved repositories
• Supplier-controlled destruction

Where required, retain disposal evidence.

---

26. Incident Reporting

Immediately report:

• Unauthorized access
• Lost Restricted document
• Unauthorized download
• Wrong-recipient disclosure
• Public exposure
• Lost device
• Credential exposure
• Suspicious access
• Unauthorized copying
• Accidental upload
• Unauthorized third-party access

Report to:

[Security Team / Incident Manager / Information Owner]

Do not attempt to hide, alter, or destroy evidence.

---

27. Business Continuity and Backup

Where Restricted information is required for business continuity:

• Backups must receive appropriate protection.
• Access must be restricted.
• Encryption should be used where appropriate.
• Backup locations must be controlled.
• Restoration should be tested where required.
• Backup retention must be defined.
• Recovery access should be appropriately restricted.

---

28. Document Version Control

Version	Date	Change	Author	Reviewer	Approver
1.0	[Date]	Initial version	[Name]	[Name]	[Name]
1.1	[Date]	[Change]	[Name]	[Name]	[Name]
2.0	[Date]	[Major Change]	[Name]	[Name]	[Name]

Only the current approved version should normally be used.

---

29. Distribution Register

For documents requiring formal distribution tracking:

ID	Recipient	Organization	Purpose	Access Level	Method	Expiry	Approved By	Status
R-001	[Name]	[Organization]	[Purpose]	Read	Secure Portal	[Date]	[Name]	Active
R-002	[Name]	[Organization]	[Purpose]	Read/Edit	Restricted Repository	[Date]	[Name]	Active

---

30. Restricted Information Handling Checklist

Before access

• Business need confirmed.
• User authorized.
• Information owner identified.
• Access scope defined.
• MFA/strong authentication enabled where required.

Before sharing

• Recipient verified.
• Business purpose confirmed.
• Owner approval obtained.
• Contractual/privacy requirements checked.
• Secure transfer method selected.
• Access expiry defined where possible.

During use

• Information stored only in approved locations.
• Unnecessary copies avoided.
• Screens protected from unauthorized viewing.
• Credentials kept separate and protected.
• AI/third-party tools approved.

After use

• Temporary copies deleted.
• Access removed when no longer required.
• Documents returned or deleted where applicable.
• Distribution records updated.
• Disposal evidence retained where required.

---

31. Example – AWS SaaS Startup

A Restricted document contains details of the organization’s AWS production security architecture.

It includes:

• AWS account structure
• Privileged IAM roles
• Production network architecture
• Security Group configuration
• Administrative interfaces
• Monitoring architecture
• Security response procedures

Handling requirements:

Create → Classify Restricted → Store in restricted repository → Grant access to authorized security/engineering personnel → MFA → Log access → Review access → Remove obsolete copies → Securely dispose

The document should not be uploaded to a public GitHub repository, shared through an unrestricted cloud link, or entered into an unapproved AI service.

---

32. Responsibilities

Role	Responsibility
Information Owner	Determines classification and approves access
Document Owner	Maintains the document and distribution
Security/ISMS Manager	Defines security requirements and monitors compliance
IT/Cloud Team	Implements technical safeguards
System Owner	Controls system-specific access
Employees	Follow Restricted information requirements
Contractors	Use information only for authorized purposes
Management	Approves access where required
Internal Audit	Independently verifies applicable controls

---

33. Evidence

Potential audit evidence includes:

• Restricted Document Register
• Access approvals
• Access-control lists
• IAM records
• MFA configuration
• Access review records
• Document distribution records
• Secure transfer records
• Encryption configuration
• DLP records
• Cloud access logs
• Download/export logs
• Supplier agreements
• Confidentiality agreements
• Disposal records
• Incident records
• Security monitoring alerts
• Training and awareness records

---

34. Common Mistakes

Avoid:

• Giving Restricted access to an entire department.
• Using shared accounts.
• Keeping permanent access when temporary access is sufficient.
• Sending Restricted information through ordinary email.
• Storing secrets in documents unnecessarily.
• Uploading Restricted information to public repositories.
• Sharing unrestricted cloud links.
• Entering Restricted information into unapproved AI tools.
• Keeping obsolete copies.
• Failing to revoke access after project completion.
• Treating a classification label as a substitute for actual security controls.

---

35. Relationship With Other ISMS Documents

This template should operate together with:

• Information Security Policy
• Information Classification Policy
• Data Handling Guidelines
• Information Handling Procedure
• Information & Asset Inventory
• Asset Ownership Register
• Access Control Policy
• Access Revocation Checklist
• Employee Offboarding Checklist
• Contractor Offboarding Checklist
• Remote Working Policy
• BYOD Policy
• AI Acceptable Use Policy
• SaaS Application Register
• Supplier Security Assessment
• Incident Response Plan
• Data Breach Response Procedure
• Asset Lifecycle Management Procedure
• Risk Register
• Regulatory Compliance Register

The overall relationship is:

Information → Classification → Owner → Risk → Access → Protection → Monitoring → Sharing → Retention → Disposal → Evidence

---

36. ISO 27001 Connection

Restricted information handling may support applicable requirements relating to:

• Information classification
• Access control
• Access rights
• Privileged access
• Information transfer
• Data leakage prevention
• Secure authentication
• Cloud security
• Supplier security
• Secure disposal
• Logging and monitoring
• Protection of sensitive information
• Privacy and protection of personal information

The organization should determine the exact applicable controls through its risk assessment and Statement of Applicability (SoA).

---

37. Final Audit Trail

A mature Restricted Information process should demonstrate:

Identify → Classify → Assign Owner → Assess Risk → Authorize → Store Securely → Access → Monitor → Share Securely → Review → Revoke → Retain → Dispose → Evidence → Improve

Final Principle

Restricted information should be accessible only to the right person, for the right reason, for the right period, using the right security controls — with evidence that access and handling were properly managed.