This might seem too obvious to ask: "Our security goals are to have no break-ins, no stolen data, no cybervandalism, and no successful malware attacks, you chump." And this would be an admirable set of goals if they weren't a great example of optimizing the part at the expense of the whole -- because these goals are easily achieved. All a company has to do is shut down its internal networks and Internet connections. If the company isn't willing to do that, it has to reformulate its security goals to recognize the need to balance risk and effectiveness, and describing an optimization that's a balance among multiple competing goals is a far more difficult formulation to create.
Which means the answer is going to be more complicated than anyone will like, might be more complicated than anyone would be willing to accept and certainly will be more complicated than anything I can fully answer within the framework of Advice Line. To get to a good answer would probably require a week of on-site consulting -- not that I'm not trying to sell you a week of on-site consulting, just giving you a sense of the magnitude of the challenge. (Not that I'd complain if you asked.)
Anyway, here's the shape of an answer, to get you started:
Begin by defining IT's operational goals for performance, stability, and ease-of-use. Ease-of-use is an excellent example of the well-known inverse relationship between the importance of a goal and the difficulty of measuring it objectively; neglect to measure it, though, and you won't get it, which is worse.
Second, you need a threat inventory. This is your list of the types of attacks you know you need to plan for. It should take the form of a hierarchical list, starting with something akin to the "chump" goals I listed above, drilled down a few levels, until everyone responsible figures you have a good handle on the types of threats you face.
Third, establish the concept of "acceptable countermeasures." An acceptable countermeasure helps achieve a security goal without degrading performance, stability, or ease-of-use beyond x. Of course, "x" can't be defined numerically until you figure out how to measure performance, stability, and ease-of-use.
Next is defining security goals. This is where it gets interesting, because you live where meteorologists live: They can "predict" a 30 percent chance of rain tomorrow, but when tomorrow shows up it either rains or it doesn't. In your world, here's the best I can come up with: Your goal for each item in the threat inventory is to have implemented acceptable countermeasures that are at least as good as industry standard practice (usually and incorrectly called "best practice") for that threat category.
Two points on this: First, industry standard practice is a moving target; it improves over time, which means your own practices have to improve over time as well. This is a good thing.