Although you may use your incident response program daily, it is important to test the process. Invite key stakeholders to participate in the testing process. The testing group stakeholders may include privacy, information security, legal, corporate communications, risk management and human resources. Testing of your incident response program is important to ensure that the process works for the current environment: Does it cover all international, federal, state and contractual obligations? Take this time to identify any areas in need of improvement or gaps, to review related tools and resources and to check that everyone involved in the process understands their roles and responsibilities.
The process should be tested at least annually to ensure that roles and responsibilities, policies, procedures, related tools and resources are up-to-date and still applicable. A review of the prior year’s incident response issues, any roadblocks and lessons learned should be reviewed with the group. This will help level-set the group members and keep these issues fresh in their minds throughout the testing process. You may want to start by drafting multiple case scenarios that need to be tested. Include low- and high-risk issues and small and large number-of-impacted scenarios to test the effectiveness of your program across a variety of circumstances.
Walk testers through the testing process, why you are doing it and what your expectations are of the group. When testing the process, you can have the team perform all activities related to the incident—everything from the report coming in, to the tracking back to root cause, to performing risk assessment, providing the notification, etc. Or if you use your incident response program on a regular basis, you may be able to have the group just verbally talk through each process. Your testing plan should be specific to your program. Be sure to review all of the key activities that would normally take place in relation to the scenario. Make sure that you address each of the items listed below.
Review roles and responsibilities. Make sure that everyone understands their roles, their roles and responsibilities are documented and they agree with what is included in the related documentation. Often roles and responsibilities change throughout the year, and new responsibilities may need to be documented.
Review policies and related procedures with testing team. Make any updates or improvements to the process and make sure all documentation is up-to-date and in a format that can easily be given to regulators if requested. Make sure that you have processes documented for both low- and high-risk incidents, and reference any related tools and resources.
Does testing team know where to go to research an incident? Are key contacts for systems or business areas written down? Does the team know who to contact to pull data related to an incident? Do those contacts know what to do when you contact them? Do they understand their roles and responsibilities?
Identify any vendors related to the process. Do you have a credit-monitoring vendor? Do you have a vendor lined up to help with breach notification in a large incident? Are you happy with their services? Any concerns? Do you have the proper agreements in place, and are they up-to-date? Do vendors understand your expectations and what services you want them to provide? You do not want to leave these activities until you’re buried in the middle of an actual incident. You may want to occasionally meet with your vendors to review services and your expectations with them. Have the group help you identify additional services or vendors that would help enhance your program.
Document your testing process, the results and any actions that are to be taken as a result of the findings. Taking the time to test your program annually will help you keep it fresh, provide an opportunity for continuous improvement and help identify gaps or inconsistencies. You do not want to find yourself in the middle of an incident and realize that you do not have what is needed to respond efficiently and effectively.
Did you miss the first parts in this series? Click to find posts one, two , three, four and five.