Information Classification and Handling Policy

Document control

Field	Value
Document status	Active policy document
Owner	Security / Operations
Approver	Management
Review frequency	Annual or on material change
Classification	Customer-shareable

Purpose

This policy defines how Hybrowlabs classifies, labels, handles, stores, shares, transmits, retains, and disposes of information based on sensitivity.

The objective is to ensure that company, customer, employee, vendor, operational, legal, financial, and security information receives protection appropriate to its risk and business value.

Scope

This policy applies to all information handled by Hybrowlabs, including:

• Customer data and customer documents.
• Employee, contractor, applicant, and HR records.
• Business, financial, legal, and commercial records.
• Source code, configuration, logs, and technical documentation.
• Security reports, vulnerability findings, architecture documents, and audit evidence.
• Credentials, API keys, certificates, tokens, and secrets.
• Emails, chat messages, tickets, spreadsheets, screenshots, exports, backups, and attachments.

This policy applies to employees, contractors, vendors, subprocessors, and any other authorized users who access Hybrowlabs or customer information.

Classification levels

Hybrowlabs uses four classification levels.

Classification	Description	Examples
Public	Information approved for public release.	Website content, public brochures, approved case studies, published job posts.
Internal	Non-public business information intended for Hybrowlabs personnel or approved internal users.	Internal process notes, internal project plans, team updates, non-sensitive templates.
Confidential	Sensitive information that may harm Hybrowlabs, customers, employees, vendors, or business relationships if disclosed without authorization.	Customer documents, contracts, pricing, implementation details, architecture summaries, internal reports, non-public business data.
Restricted	Highly sensitive information requiring strict access control and handling. Unauthorized disclosure may cause serious security, privacy, legal, financial, or contractual impact.	Credentials, secrets, personal data, payroll/HR records, VAPT reports, incident details, security findings, regulated data, production exports, private keys.

If classification is unclear, information must be treated as Confidential or Restricted until the owner confirms otherwise.

Classification principles

• Information must be classified based on sensitivity, business impact, legal/contractual obligations, and potential harm from unauthorized disclosure.
• Classification must follow the data, even when copied into another format such as screenshots, spreadsheets, emails, logs, or exports.
• Combining multiple lower-sensitivity datasets may increase classification if the combined set becomes more sensitive.
• Customer information should be treated as Confidential by default unless clearly approved for public release.
• Credentials, secrets, and security findings must be treated as Restricted.
• Personal data must be handled at least as Confidential, and as Restricted when sensitive, high-volume, or high-risk.

Ownership

Each information asset should have an owner responsible for:

• Assigning or confirming classification.
• Approving access and external sharing.
• Defining retention expectations.
• Ensuring deletion or return when no longer required.
• Reviewing exceptions and unusual use cases.

Where ownership is unclear, the relevant project owner, department owner, or management should be consulted before sharing or deleting the information.

Labelling requirements

Where practical, documents and repositories containing sensitive information should be labelled using the classification level.

Examples:

• Confidential - Customer Implementation Notes
• Restricted - Security Assessment Summary
• Internal - Delivery Process SOP
• Public - Approved Marketing Brochure

Labelling is especially important for externally shared documents, security reports, HR records, legal documents, and customer evidence packs.

Handling matrix

Control area	Public	Internal	Confidential	Restricted
Access	Open after approval for release	Hybrowlabs personnel / approved users	Need-to-know only	Explicitly authorized users only
External sharing	Allowed if approved public content	Only with approval	Owner approval required	Management/security/data-owner approval required
Storage	Public systems permitted	Approved business systems	Approved access-controlled systems	Approved restricted-access systems only
Transmission	Standard channels	Business channels	Controlled business channels	Secure channel, restricted recipients, optional encryption/password protection
Local copies	Allowed	Minimize	Temporary only if needed	Avoid unless explicitly required; delete after use
Retention	As published/needed	Business need	Contract/legal/business need	Minimum required period; review regularly
Disposal	Normal deletion	Normal deletion	Secure deletion where appropriate	Secure deletion / access revocation / return evidence where required

Storage requirements

Public information

Public information may be stored in approved public systems after release approval.

Internal information

Internal information should be stored in approved business systems and should not be posted publicly unless reviewed and approved.

Confidential information

Confidential information must be stored in access-controlled business systems. Access should be limited to personnel with a legitimate business need.

Examples of approved controls:

• Named-user access.
• Role-based folders or systems.
• Restricted project workspaces.
• Access revocation after project completion.
• Avoidance of broad/public links.

Restricted information

Restricted information must be stored only in systems appropriate for sensitive data, with strict access controls.

Additional expectations:

• No public links.
• No broad group access.
• No long-term local storage unless explicitly approved.
• No storage in personal accounts.
• No storage in source control unless the repository is explicitly designed for that purpose and access-controlled.
• Encryption or password protection where appropriate.

Sharing requirements

Before sharing Confidential or Restricted information, confirm:

• The recipient is authorized.
• There is a valid business purpose.
• The data owner has approved sharing where required.
• Only the minimum required information is included.
• Unnecessary personal data, credentials, or unrelated customer data has been redacted.
• The sharing channel is approved.
• Access expiry or revocation is considered.

External sharing

External sharing requires additional care.

Confidential information

Confidential information may be shared externally only when:

• It supports an approved business purpose.
• The recipient is known and authorized.
• The owner or responsible manager has approved sharing.
• The document has been reviewed for unrelated or sensitive content.

Restricted information

Restricted information may be shared externally only when explicitly required and approved.

Examples requiring extra approval:

• Security reports.
• Vulnerability details.
• Personal data exports.
• Payroll/HR data.
• Credentials or access material.
• Incident records.
• Detailed architecture or system configuration evidence.

For Restricted external sharing, prefer a summary or redacted evidence instead of raw files where possible.

Email and messaging rules

• Do not send Restricted information to broad groups.
• Do not include secrets or passwords in plain text.
• Do not forward customer data to unauthorized recipients.
• Verify recipients before sending sensitive attachments.
• Use approved secure links instead of attachments where appropriate.
• Remove unrelated email history before forwarding sensitive threads.
• Do not paste sensitive data into public or unapproved chat channels.

Screenshots, exports, and logs

Screenshots, exports, and logs often contain more sensitive data than intended.

Before sharing:

• Crop or redact unnecessary fields.
• Remove tokens, session IDs, API keys, passwords, and internal secrets.
• Remove unrelated users, customers, and records.
• Avoid sharing full database exports unless specifically approved.
• Avoid exposing file paths, internal configuration, or vulnerability details unless required.

Credentials and secrets

Credentials and secrets are always Restricted.

Examples:

• Passwords.
• API keys.
• Access tokens.
• SSH keys.
• Private keys.
• Database credentials.
• Cloud or platform access keys.
• Signing certificates.

Requirements:

• Store secrets only in approved secret-management or restricted configuration mechanisms.
• Do not send secrets through normal email/chat unless explicitly approved and unavoidable.
• Do not commit secrets to source code.
• Rotate exposed or accidentally shared secrets.
• Remove secrets from documents, screenshots, logs, and tickets before sharing.

Personal data handling

Personal data must be handled according to privacy and data protection requirements.

Minimum requirements:

• Access only for authorized business purposes.
• Share only the minimum necessary fields.
• Mask or redact where possible.
• Store in approved systems.
• Delete temporary copies when no longer needed.
• Do not use personal data in demos, testing, analytics, or third-party tools without approval.

High-volume personal data, payroll/HR records, identity documents, and sensitive personal information should be treated as Restricted.

Source code and repositories

Source code may contain business logic, security controls, integration details, and sometimes accidental secrets.

Requirements:

• Repository access must be role-based and approved.
• Private repositories must not be shared externally without authorization.
• Secrets must not be committed.
• Security-sensitive code or configuration should be reviewed before external disclosure.
• Repository exports should be treated as Confidential or Restricted depending on contents.

Security reports and vulnerability information

Security reports, vulnerability findings, penetration-test reports, exploit details, and remediation evidence are Restricted unless formally approved for broader sharing.

Handling requirements:

• Limit access to security, engineering, management, and authorized customer contacts.
• Share executive summaries where detailed exploit evidence is not needed.
• Redact unrelated systems, credentials, personal data, and internal-only notes.
• Track external sharing of security reports.

Retention and disposal

Information must be retained only for required business, legal, contractual, operational, or security purposes.

Disposal methods may include:

• Deleting files from approved systems.
• Revoking shared links/access.
• Purging temporary folders.
• Removing local downloads.
• Letting backups expire according to backup lifecycle.
• Returning documents to the customer where contractually required.
• Secure destruction of physical copies.

Restricted information should have stronger deletion evidence where required.

Exception handling

Exceptions to this policy must be documented and approved.

Exception records should include:

• Information involved.
• Classification level.
• Business reason.
• Risk.
• Compensating controls.
• Owner.
• Approver.
• Expiry or review date.

Examples of exceptions:

• Temporary local storage of Restricted data for migration.
• External sharing of a security report.
• Use of a non-standard sharing channel during an urgent incident.
• Extended retention due to legal or contractual need.

Incident reporting

The following must be reported immediately:

• Sensitive information sent to the wrong recipient.
• Public link created for Confidential or Restricted information.
• Lost/stolen device containing sensitive data.
• Secret committed to source code.
• Unauthorized access to customer or personal data.
• Security report or incident record shared without approval.
• Unapproved third-party upload of sensitive data.

Initial containment may include revoking links, deleting files, rotating credentials, disabling access, notifying recipients, or escalating to management/security.

Training and awareness

Personnel handling Confidential or Restricted information must understand:

• Classification levels.
• Approved sharing channels.
• Redaction and minimization.
• Personal data handling.
• Credential and secret handling.
• Incident reporting.
• Customer confidentiality obligations.

Training should be provided during onboarding and periodically thereafter.

Review and maintenance

This policy must be reviewed at least annually or after:

• A data exposure incident.
• A customer audit finding.
• A major system/process change.
• Changes in legal or contractual requirements.
• Repeated exceptions or sharing mistakes.

Evidence to maintain

• Approved Information Classification and Handling Policy.
• Classification matrix.
• Access approval records.
• External sharing approval records.
• Redaction/sanitization evidence where applicable.
• Data retention/deletion evidence.
• Exception register.
• Security/privacy incident records.
• Training and acknowledgement records.