Information assets, including printed materials, email attachments, or other data, should be classified appropriately to ensure they are handled securely.
Organizations may not have the appropriate security controls in place for sensitive assets if classification levels are not defined. The process of classifying assets, along with defining associated security requirements, helps reduce the likelihood of sensitive information being provided to, or viewed by, unauthorized parties. The classification, labeling, and handling of assets is the focus of pitfall #24 in my eBook, Security Program Pitfalls and Prescription to Avoid Them.
Information assets should be classified in terms of business value, legal requirements, sensitivity, and criticality to the organization. A classification schema should be established that differentiates between the various levels of sensitivity and value of information assets, or groups of information assets.
Once the number of classification tiers have been defined, they should be documented in a policy, such as the Asset Management Policy. A description for each classification tier should also be documented that is appropriate for your organization. For example:
- Public: Low Sensitivity. This type of data is freely accessible to the public. It can be used, reused, or redistributed without repercussions. Loss or compromise is reasonably expected to have negligible impact on the organization. Examples include job descriptions, press releases, or public web site content.
- Internal Use Only: Medium Sensitivity. Access to this type of data is strictly limited to internal personnel who have been authorized access. Loss or compromise could reasonably be expected to have a significant impact on the organization. Examples include internal memoranda, policies, emails, or other documents that do not contain confidential data.
- Confidential: High Sensitivity. This type of data requires specific authorization for access. Loss or compromise could reasonably be expected to have a catastrophic impact on the organization. Examples include financial records, M&A documents, intellectual property, trade secrets, and data that is required to be protected by legal or regulatory requirements.
To learn more about this pitfall, and 99 more, get my book: 100 Security Program Pitfalls and Prescriptions to Avoid Them (available on Amazon here). Or register for a demo of the ASECENT Security and Compliance Portal and get a free synopsis of the 100 Security Program Pitfalls eBook today.