Building on @AdHominem's good answer, I would add that your organization should have a security policy that clearly lays out your information classification guidelines. It's common to define three or four levels, such as "public", "internal", "confidential", and "sensitive". With each level, the policy should state very clearly what can happen with information at that classification: 'public information can be shared with anyone without consequence', 'confidential information may not be shared with anyone outside of the department without director approval or higher', 'sensitive data must be encrypted at rest', etc. Your security policy should also define how to evaluate your data: "if releasing the data to the public would cause moderate reputation damage, it must be classified as confidential", "if releasing the data to the public would cause a violation of SEC laws, it must be classified as sensitive", that sort of advice.
You need the policy to be unambiguous in order to avoid protracted arguments over "why does my department have to pay the full cost for the encryption library when department X has the same data but doesn't encrypt it?"
Your security policy also has to take into account external regulations, laws, and contractual obligations. If the PCI DSS rules say "you must encrypt the account number with 2048-bit RSA", it doesn't matter if your data owner calls it confidential, your security policy must accommodate these regulations and enforce the required encryption.
Note that corporate classifications are generally different than military classifications. Military uses often include the concept of "clearance", which is a rating of the person who will have access to the data.
Also be aware that sensitivity may be context dependent. A postal code is public information. But the same postal code associated with the row of data associated with John Smith may be confidential, because it could damage your reputation to violate John Smith's privacy. And if the postal code is associated with John Smith's credit transaction, it might be considered sensitive according to PCI rules. HIPAA/Privacy rules are rife with these kinds of issues.
If your organization doesn't already have a security policy and you're asking these kinds of questions, it's time to implement one. If you need help, know that there are several resources on line, but you will obtain better results using a qualified CISSP to help create one. Also, be aware that your security policy will come into play if there's ever a lawsuit resulting from a breach. Not having a policy will almost certainly be called out by the plaintiffs as a sign that your organization is irresponsible with data security. You need your organization's lawyers to be on board with it. (Defending against lawsuits is just another ugly part of risk management.)
And if your organization does have a security policy, it is already your responsibility to read it, understand it, and follow it. If it doesn't have information classification spelled out clearly, speak to your Info Sec people and ask them to review it for inclusion it in the next update of the policy (the security policy should have a policy review frequency written in it.)