This is a draft post I just ran across. I'm publishing it "as is" in case it may be useful to someone; sorry for the fragmented post.
Over the last year and a half (and arguably three) years I have been wrapping my head around tracking and reporting of incidents. This is an account of some the rules I have used up to this point. Some issues are easy, some are hard.
use a platform
KISS- stay away from complexity
treat it like an object:
enumerate attributes of incident
enumerate methods applied to incident
enumerate methods applied to a range of incidents
maintain confidentiality when possible; but don't sacrifice usability if the risk to confidentiality is low.
understanding severities
I loosely based how I classify severities as to the F-scale tornado classification. The F-Scale is based on describing the damage done as opposed to describing the actual event. I feel this is an important distinction as you can't realistically enumerate every incident/attack and doing so is futile. So don't try. instead create attributes or characteristics that are important to you. Good examples of attributes: scope, activity, impact, loss. Based on the attribute, a qualitative decision is made as to the severity. There are also times when a certain severity is mandated. This is typically based on legality requirements. For example a loss of PII, or health records should be a threshold event that immediately creates a higher severity level.
create rules of engagement based on severity levels.
if you don't know how many incidents were opened last week then you're not yet successful.
utilize new stuff. Like tagging.
Do not reinvent the wheel. Utilize NIST 800-61 when possible.
Do not reinvent the wheel. Use existing platforms.
