Tag Archives: guidelines

Information classification: practical guidelines

Some information security standards or best practices require organizations to have an information asset classification policy. ISO27002 1 requires an information classification policy; The NIST has even published a FISP2 on the topic, PCI-DSS 3 doesn’t speak about it as it focuses on Credit Card information considered as sensitive information by default; and IT-Grundschutz4 require potential damage and protection requirements classification.


Even if some people will consider the need for compliance with security standard a sufficient reason, the real purpose of such policy is normally to differentiate valuable and critical information from other information in order to provide an appropriate level of protection and keep the residual risk low. Objectives of an information classification policy should likely be:

  • Simplification of risk assessment process
  • Proportionate cost of protection
  • Consistent and adequate protection of information throughout its lifecycle;
  • Fosters adequate behaviours when handling information, independently of its form.

The three first goals are common risk based security benefits. The fourth is more typical to information classification. As you define classification for information and assets, you put label on them informing users how valuable are the assets and how we are expected to behave with it. In behavioural terms, classification is the first step to a good conditioning. The label is the stimuli that shall trigger the appropriate behaviours.

However, as logical this may sound in theory, in real life, the goal does not seem so easy to achieve.

Common issues

Most government agencies, armies, financial institutions or large corporations have an information classification policy or an asset classification policy. A January 2008 report of the US Office of the Director of National Intelligence on information classification guidance 5 underlines several common issues encountered with information classification policies within US government agencies (mostly defence).

The report points out the “little insight into the reason for setting classification and limited guidance for discriminating between classification levels”. Also, operational difficulties are often observed has some rules or criteria are sometimes conflicting or, too often, not understood, leaving the user in an administrative nightmare leading to inadequate classification. This report also reminds the relationship between information sharing and information classification: sometimes the latter may be an obstacle to the first.

In an other report on US information classification, coming from the US Congress Congressional Research Service 6, the author highlight the growing cost of information classification and the downward trend of the number of declassification, resulting in a vexing cost for the government. Such a report showing issues with information classification inside a security minded community like the US defence agencies is likely to show only the tip of the iceberg of what less security culture prone organizations might face.

For what its worth, we made a list of common issues we encountered during our various assignments (in all kinds of organization like public, military, retail, finance or electronics)

  • Classification model does not fit the needs of the business (too complex, impossible to apply, not aligned);
  • Policies are not known or not well remembered;
  • Policies are not understood correctly (assets are over-classified or under-classified);
  • Reason of the existence of the policy is not understood and, consequently, motivation to apply is very low (even amongst the senior management sometimes);
  • Policies are not applied (security requirements are not met or applied, assets are not classified although the policy is known);
  • Assets’ classification does not reflect the real value or cost of damage of information but more the relative value compare to other assets (relative classification);
  • Number of exceptions to the security requirements is growing and this process is sometimes overwhelming;
  • Some risks are not covered by information classification model (compliance, fraud);
  • Information classification prevent or delay information circulation between people or entities needing this information (loss of performance);
  • Difference between different level of classification is difficult to understand;
  • Information is classified “forever” resulting in inadequate classification of information as the classification is not aligned anymore with the residual value of the information
  • Different entities sharing information don’t have compatible classification policy, jeopardizing information’s security throughout its lifecycle;
  • The scope is not well defined (too many or too few assets are classified)
  • Cost of over classification is not understood and information is systematically over classified because “you will never get fired because you were to cautious”

To change or not to change

When we notice dysfunction in a process, we ask ourselves: “should we change it?”. For sure, if it works, we don’t try to fix it. But if it doesn’t work, or, if it doesn’t work well, do we really have to change it (all)? Creating a new asset classification is one thing. Changing one is for sure another thing. If something doesn’t work you have to understand what is not working, figure out how to fix it and manage change to achieve this new desired state. It might cost a lot of time and money.

We won’t spend time on the choice of one specific model (The ROI7 model might not be as relevant as the ROSI8, even more if your security baseline is already providing a high level of protection) for the business case or on the parameters to take into account. Just remember that sometime, not fixing things may be the financially most interesting solution.

For the purpose of this article, we will suppose we have a business case and that the expected benefit will largely outweigh the expected costs (while keeping a large security margin in our estimates). We could probably use a lot of approaches to improve an existing asset classification policy. As usual, we prefer simple & pragmatic approaches.


First, we try to understand why the organization want to change the policy (known issues), what are the goals and what are the expected benefits (it should have been made clear by the business case or at least the reflexion about the funding of the project). More precisely, we will try to answer the following questions:

  • What is going well with the policy? What are the benefits of the policy?
  • What are the known issues? What are the consequences of these issues?
  • What is unknown (grey areas, immeasurable results)?
  • What are the needs or requirements (legal, regulatory, business)?
  • What is the motivation (compliance, risk reduction, increased agility,…)?
  • Was there “famous” success inside the company?
  • Was there incidents? What were the causes and consequences?
  • When has the policy been originally created?
  • Who created the original policy, for what reason?
  • How was it supported by the management?
  • How was it perceived by the personnel?
  • How is it applied?
  • What are people remembering from the policy?
  • Do people understand the need for security and asset classification?
  • Which parts of the policy are applied correctly?
  • What were the expectations when drafting the first policy?
  • Did we already try to change it before? What was the result?
  • Why do we want to change it now? What did changed recently?
  • Who is happy with the policy at the moment?
  • Who is complaining about the policy?
  • How many exceptions are processed? What are the main reasons for exceptions?
  • What is the main goal of the organization? What are the constraints (like in Lean)?
  • What are the priorities of the organization (and also, more precisely, Sharing versus protecting information)?
  • What is the level of the organization security baseline?
  • What are the organization’s values?
  • Is there a risk management policy?
  • How are risks evaluated?
  • What is the risk appetite of the organization?
  • Who are the stakeholders (decision makers, influencers, beneficiary, and impacted entities)?
  • What are the deadlines?
  • What are the success criteria? Is there related KPI & KGI?
  • How will you see (practically, not through KPI) that the new policy works?

While gathering information to answer these questions, we will be able to construct a representation of what is going wrong and likely come to a good idea of what should be improved and how to improve it (with a little creativity)?

New model(s)

At some point, we will be able to draft propositions for one (or more) new model(s) that should fix the issues or at least greatly improve the situation, in theory.

In order to reach our goal (effectiveness and efficiency of asset classification), we will apply a few requirements or constraints to this new model and its related document:

  • You must KISSS (Keep it short, simple and sexy): People don’t have time to read through hundred of pages (it cost a lot of time to the organization), to make it simple, we must make our thought clear and making it sexy (using icons, brief sentences, images or whatever communication team uses to make their document appealing) will clearly help having the document read and applied.
  • It must make sense for everybody: Everybody doesn’t have a security or risk background. You cannot expect or assume that everybody has an understanding of the reasons why we do things like classifying assets. So , you must explain it so it can make sense to the reader (it will increase the engagement)
  • You must use the organization’s culture and the daily life of the reader to select your examples and explanations (it will be easier to memorize and it will make a long lasting impression)
  • You must use positive actions to describe what you expect from the reader. So, you must define what they have to do and not what they have to not do. We, humans, tend to have difficulties to process the negative form. If what you describe can be better achieved by a dead person, it is not a good expectation.
  • Highlight, as much as possible the important words: You see why, I guess. Select carefully which words you want to highlight as too many highlighted words will make the benefit of the highlight void.
  • Use name, label, levels that make sense, intuitively. When you use different level, it can help if we clearly understand which one is higher or more important. As an example, it should seem clear to everybody that TOP SECRET is above (top) SECRET. But what is higher: SECRET or CONFIDENTIAL?
  • As much as possible, use clear and discrete categories or at least, provide the necessary criteria that should allow anybody to consistently discriminate between two categories. As example, what will make the difference between to level of integrity (precisely, measurably and operationally)?
  • If you have different categories, each category should have matching security requirements. If the requirements are the same for two categories, do you really need the two categories or shouldn’t you add new security requirements?
  • Simplify and reduce processes and documents as much as possible. Having to open two different documents to get an answer is a waste of time if it has to be done repeatedly. Having one document on privacy and another on information classification can generate a lot of redundancy.
  • Be consistent throughout the document and all policies.
  • Give as much relevant information and insight, at least the “big picture”, within the first pages of the document so readers don’t have to go through the entire document to find answers. Put the most often needed information in the first pages.
  • Make responsibilities clear as well as chain of command and the processes to follow for common actions (new document, review, declassification, incidents,…)
  • Link, as much as possible, your categories (or levels) to the risk or the potential impact.

While drafting a new model, we don’t hesitate to go beyond the classical CIA triad (Confidentiality, Integrity and Availability).  Relevancy of additional dimensions must be investigated: Retention or archiving time (often based on regulatory requirements), restitution format, privacy or any other that can make sense in your business.

Also, we would suggest to use caveats to add a sense of need-to-know to the confidentiality classification (Like EMPLOYEES ONLY or  FINANCE RESTRICTED) or to add some flexibility to the model (like RESTRICTED WHEN FILLED or AVAILABILITY CRITICAL DURING MONTHLY FINANCIAL CLOSURE). Using caveats to define the target group for information (people having the need-to-know) is certainly the most meaningful approach. When you have a RESTRICTED, SECRET or CONFIDENTIAL document (whatever your naming convention is for a very sensitive document), knowing to whom it is restricted to will be more than useful.


While gathering our information for the assessment, we also build a list of business process owners. When we have a good model, we sit together with them and we test the new model on real data “from the field”.

First, we ask business owners to read the asset classification document and to explain what they have understood. We take note of their questions, comments and misunderstandings in order to improve our document.

Then we test the model on existing processes and on common flux of information, application and documents. We validate that assets are well classified and that matching security requirements9 will be proportionate to the risks

Of course, we don’t forget to asses the complexity of the process and the impact the new model would have on business units. Security policies, in general, should bring an added value and not an extra burden on the business. Security can also be a business enabler and brings value additionally to some peace of mind.


Base on the test and discussions with the business owners, we may update the model and document (if necessary) in order to address any new issue discovered or to improve the usability of the document. We’ll do it more than once if necessary until we reach an acceptable level of understanding and acceptance of the model. Amongst the classic reviewers like legal or HR, the communication department might bring valuable insight or guidance on the tone of voice, the organization’s style and the format (remember the KISSS directive) as they are probably better at judging the simplicity and attractiveness of a document and models that you master (contrarily to your main audience)


We’ll arrive to the classic phase of having the new model approved by senior management. An executive summary and a very brief presentation of the changes and their motivation will help the senior management to understand the process leading to this new policy. Presenting the new policy to direct reports of senior managers prior to submitting it for approval will also likely facilitate the process as it will build the trust and the awareness on the new classification model.


Once the document approved, the job is far to be finished. In fact, it is just the beginning and the easiest part is now over. It is likely that the changes we made to the classification model are relatively small hence significant. However, we must also adapt the organization’s processes and change people behaviours. Likely, we will, in fact, have to change people’s attitude and behaviours in such a way that they will start applying a policy they were previously ignoring.

Lead by example

“Be the change you want to see in the world”. This quote, sometimes attributed to Ghandi, is likely the first advice to follow when we want to change something in an organization. “Leading by example” should be more than a smart quote from expensive People Management training. The first person we need to educate about information classification is surely senior managers. We cannot assume they know how, what or why we do asset classification it is not their job. Their job is to make it applied by all their reports. If we fail showing senior managers the benefits of information classification, it is likely we will have huge difficulties to make it apply across the organization. If your boss doesn’t follow the rule, you will understand that the rule is not important and you will be less likely to follow the rule yourself. If he insist you follow the rule but he still doesn’t, we call that paradoxical communication (do what I say, not what I do) and it is the worse way to induce change.

So, if we want to have a return-on-investment on an asset classification model improvement, we need time with senior manager to show them the expected benefits and how it will work, to make them the first ambassadors of our new model.

Tone of voice

When we want to convince people of changing something in their life, we have to be convinced ourselves first. Consequently, we will likely use wording and tone showing we are convinced, raising the probability of being followed by our audience. We must speak in positive terms, consider people as intelligent and of good will (else we shall believe your organization must have a real recruitment issue). We keep in mind that we speak to responsible adults (We don’t patronize). We appeal to their inner sense of doing the things right. We also give as much freedom and responsibility as possible. We have to believe in their ability to do it right (if we don’t, we will create the condition for our failure).

Being pragmatic

We must keep it as simple as possible. There is (too) often too much bureaucracy slowing down the core business. If we classify documents, we prepare templates taking classification into account, where you just have to select the classification when creating the document. Same thing with be made for emails. We will display labels in sensitive applications, order stamp for paper documents, letters and folders.

In fact, based on the list of security requirements matching the new classification model, we will list all the necessary changes or supporting assets that will be needed. Here is a fairly comprehensive list (but unfortunately not yet exhaustive) of what should be taken into account:

  • safe, locks, secure cases,
  • shredders, demagnetizer
  • screen filters, secure room, signal jammers, secure phone
  • alarms, UPS, monitoring, IPS, IDS,
  • encryption software, secure USB storage,
  • Backup systems, external hard drives
  • Logical access approval process, change management, asset management
  • NDA, standard contracts, standard RFP
  • Labels, stamps, envelopes
  • Templates
  • Emergency Response procedure, Incident management, BCP, DRP
  • Double encoding process
  • Remote whipping
  • Awareness material, training sessions
  • Central database of asset’s classification and owners


As always, we will not have a managed security if we don’t measure our successes or failures. Directly or indirectly , we will monitor the effect of the new policy: Incident rates and costs, awareness campaign results (through questionnaires),  number of classified assets, audits, tests. As much different indicators you have, the more accurate the measure will likely be.

That’s all folks!


1 International Standard Organisation, Standard 27002 (version of 2005): “Information technology – Security techniques – Code of practice for information security management“ – [http://www.iso.org]

2 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION 199: “Standards for Security Categorization of Federal Information and Information Systems” [http://csrc.nist.gov/]

3 Data Security Standard from the Payment Card Industry [https://www.pcisecuritystandards.org/security_standards/]

4  Best practices from German Information Security Agency (BSI Standard 100-1) – [https://www.bsi.bund.de/]

5 Office of the Director of National Intelligence “Intelligence Community Classification guidance: Findings and recommendation report“ [http://www.fas.org/sgp/othergov/intel/class.pdf]

6 US Congress Congressional Research Services report for Congress: “Security Classified and Controlled Information: History, Status, and Emerging Management Issues’ [http://www.fas.org/sgp/crs/secrecy/RL33494.pdf]

7 Return on Investment

8 Return on Security Investment

9 If security requirements are not yet defined, we can just compare the assets (documents, applications, systems) between them and see if the same kind of controls will make sense on the group of assets created by the classification