Information types should be defined as narrowly as possible while still making sense. These are the discrete elements that make up all the information your organization holds and knowing what type of information exists in each system is very valuable. It takes a bit of work on the front end, but that work pays off when you try to understand the risk of holding such data and knowing where the information is held. For example, if you learn that you are performing penetration testing and want to know which systems would result in required customer reporting, you can easily run a report to identify which systems have social security numbers or driver’s license numbers along with names. So a customer contact database would probably have elements defined as: “customer name”; “customer home address”; “customer phone number”; and “customer account number”. There would likely be many more, but this gives the idea. A general description like “customer information” would not be helpful.
Describing information types becomes tricky when addressing unstructured data sets like emails. It is really hard to know what type of information someone will send in an email and if the organization does not have a requirement that emails must be stored somewhere other than in the email server, it is even harder. But you can do your best and try. Speak to the users and see how they use the system and what types of transactions are performed with the system. That will give you an idea of the type of information held in the system. You won’t get it all, but you will be surprised by how much you do learn. You may also learn that using email for some of the work your organization performs is too risky and develop other safer pathways to perform the same tasks.