This document attempts to establish guidelines, procedures, or policies for securing our systems when normal controls are not available.

Compensating controls are not a short cut to compliance, they do not have a defined life-span, and are not here to make our compliance effort easier.   However, in the context of our objectives, we need flexibility to respond to various known and unknown events that may affect our systems.  We have this alternative process in place to give us flexibility as long as we do these three things:

• Protect the confidentiality of information.

• Capture all material changes to systems and configurations.

• Restore mission critical systems quickly and recover all systems completely within promised availability windows.

To meet the above objectives we do the following:

• Plan ahead.  Our compliance and disaster process offers a variety of scenarios all of which enable our teams to solve specific issues, but also informs our teams about the though process and approach so that unknown issues are less of an obstacle.  For this we leverage some internal assets including:

  • Automation/scripting repositories 

  • Operate multiple communication channels to enable information sharing, collaboration, and also maintain communication in the event of a disaster.

    • Primary Example: Slack and  Google Workspace

    • Backup Example: Microsoft Teams and Microsoft Exchange Online

  • Maintain a transparent record of change which allow majority of staff to see "what changed last".

• Prepare written procedures/policies/documentation.

  • Compliance and Policies

  • Continuity and Disaster Response

  • Information Technology Operations

• Cross-train.

  • Use  {{medium}} to share important information and expand our team's knowledge.

  • Document internal procedures for solving problems via {{medium}}

Should the BCP be activated, the {{name/role}} assumes leadership of the event and may delegate functions/tasks to the disaster response team.  The  {{name/role}} may nominate self, or another individual to act as the "Person in Command" of the incident.  This person is then:

• (a) is directly responsible for, and is the final authority as to, the response process.

• (b) during an emergency requiring immediate action, the person in command may deviate from any rule of this part to the extent required to meet that emergency.

• (c) the person in command who deviates from a rule under paragraph (b) of this section shall, upon the request of the  {{name/role/team}}, send a written report of that deviation to the  {{name/role/team}} and/or Board.

To facilitate reporting in above paragraph (c), the response team is required to maintain a log of activities - as detailed as practical - during the event.  Options for keeping this log are listed in order of importance/usefulness but can be mixed and matched to meet the circumstances:

• Using screen capture/recording software to record activities.

• Using the Security Incident Reporting form to manually log activities.

• Using a living document such as Google Doc, OneDrive document, OneNote, Evernote or similar to track activities.

• Taking screen shots frequently for later review.

• Taking video/audio recordings.

• Writing down notes on paper.

In addition, logs and configuration files may not be destroyed during a security event, incident, or disaster.  All log files must be preserved for review. 

• Scripts and automation systems all maintain logs/trails of all activities.

• Volume Shadow Copy is enabled on all our systems which will be used to validate any log/config changes or deletions.

• Log and file backups are enabled for all systems which will provide further cross-check.

If the BCP plan is activated, a member of the {{team}} will assist the security/operations teams in restoring data and act as a "second pair of eyes" on the activities through whichever methods are practical.  This can include

• Screen sharing

• Receiving updates

• Tracking changes/logs.

The "{{compliance-team}}" will be briefed at the next scheduled meeting (see Meeting notes) of the event and the team may ask for

• a written report in addition to the documented evidence.

• a comparative review of logs/configurations with backups to verify that all changes were recorded and no evidence was destroyed.