Editable Cybersecurity Procedures
Documented procedures are one of the most overlooked requirements in cybersecurity compliance, but procedures are also a minimum expectation that an auditor is going to look for. For anyone who has written procedures, the answer for why companies routinely fail to maintain procedures is clear - it can take considerable time and effort to properly document processes. Part of that is tied to a lack of best practices around what good procedures look like - every organization tends to do something different, based on internal staff preferences or auditor pressure. This leads to a lack of standardization across departments and business functions, which can be an issue when trying to maintain "what right looks like" if a benchmark does not exist.
One of the most important things to keep in mind with procedures is that the "ownership" is different than that of policies and standards:
- Policies, standards and controls are designed to be centrally-managed at the corporate level (e.g., governance, risk & compliance team, CISO, etc.)
- Controls are assigned to stakeholders, based on applicable statutory, regulatory and contractual obligations
- Procedures are by their very nature de-centralized, where control implementation at the control level is defined to explain how the control is addressed.
Given this approach to how documentation is structured, based on "ownership" of the documentation components:
- Policies, standards and controls are expected to be published for anyone within the organization to have access to, since it applies organization-wide. This may be centrally-managed by a GRC/IRM platform or published as a PDF on a file share, since they are relatively static with infrequent changes.
- Procedures are "living documents" that require frequent updates based on changes to technologies and staffing. Procedures are often documented in "team share" repositories, such as a wiki, SharePoint page, workflow management tool, etc.
Procedures Operationalize Policies & Standards - This Is A Key Concept To Being Both Secure & Audit-Ready
We leverage the Operationalizing Cybersecurity Planning Model in creating a practical view towards implementing cybersecurity requirements. Organizations are often not at a loss for a set of policies, but executing those requirements often fall short due to several reasons. Standardized Operating Procedures (SOPs) are where the rubber meets the road for Individual Contributors (ICs), since these key players need to know (1) how they fit into day-to-day operations, (2) what their priorities are and (3) what is expected from them in their duties. When looking at it from an auditability perspective, the evidence of due diligence and due care should match what the organization's cybersecurity business plan is attempting to achieve.
The central focus of any procedures should be a Capability Maturity Model (CMM) target that provides quantifiable expectations for People, Processes and Technologies (PPT), since this helps prevent a “moving target” by establishing an attainable expectation for “what right looks like” in terms of PPT. Generally, cybersecurity business plans take a phased, multi-year approach to meet these CMM-based cybersecurity objectives. Those objectives, in conjunction with the business plan, demonstrate evidence of due diligence on behalf of the CISO and his/her leadership team. The objectives prioritize the organization’s service catalog through influencing procedures at the IC-level for how PPT are implemented at the tactical level. SOPs not only direct the workflow of staff personnel, but the output from those procedures provides evidence of due care.
The diagram below helps show the critical nature of documented cybersecurity procedures in keeping an organization both secure and compliant:
What Can Be Done To Make Writing Procedures Easier?
The good news is that ComplianceForge developed a standardized template for procedures and control activity statements, the Cybersecurity Standardized Operating Procedures (CSOP).
Given the difficult nature of writing templated procedure statements, we aimed for approximately a "80% solution" since it is impossible to write a 100% complete cookie cutter procedure statement that can be equally applied across multiple organizations. What this means is ComplianceForge did the heavy lifting and you just need to fine-tune the procedure with the specifics that only you would know to make it applicable to your organization. It is pretty much filling in the blanks and following the helpful guidance that we provide to identify the who / what / when / where / why / how to make it complete.
Take a look at an example to see for yourself. We even provide a matrix to help identify the likely stakeholders for these procedures. There are five (5) versions of the CSOP:
- CSOP - Digital Security Program (DSP) (directly maps to the Secure Controls Framework (SCF))
- CSOP - NIST 800-53
- CSOP - ISO 27002
- CSOP - NIST Cybersecurity Framework
- CSOP - NIST 800-171 (part of the NIST 800-171 Compliance Program (NCP))
Procedure Documentation Expectations
Procedures should be both clearly-written and concise, where procedure documentation is meant to provide evidence of due diligence that standards are complied with. Well-managed procedures are critical to a security program, since procedures represents the specific activities that are performed to protect systems and data. The diagram shown below helps visualize the linkages in documentation that involve written procedures:
- CONTROL OBJECTIVES exist to support POLICIES
- STANDARDS are written to support CONTROL OBJECTIVES
- PROCEDURES are written to implement the requirements that STANDARDS establish
- CONTROLS exist as a mechanism to assess/audit both the existence of PROCEDURES / STANDARDS and how well their capabilities are implemented and/or functioning
- METRICS exist as a way to measure the performance of CONTROLS
What Can Go Wrong If I Do Not Have Written Procedures?
What can possibly go wrong with non-compliance with a law, regulation or contract?
- Contract Termination. It is reasonably expected that the other party will terminate contracts over non-compliance with major cybersecurity and privacy requirements since it is a failure to uphold contract requirements. Subcontractor non-compliance may also cause a prime contractor to be non-compliant, as a whole.
- Criminal Fraud. If a company states it is compliant when it knowingly is not compliant, that is misrepresentation of material facts. This is a criminal act that is defined as any act intended to deceive through a false representation of some fact, resulting in the legal detriment of the person who relies upon the false information (e.g., False Claims Act).
- Breach of Contract Lawsuits. Both prime contractors and subcontractors could be exposed legally. A tort is a civil breach committed against another in which the injured party can sue for damages. The likely scenario for a non-compliance related tort would be around negligence on behalf of the accused party by not maintaining a specific code of conduct (e.g., no documented procedures).
- Fines. The Federal Trade Commission (FTC) has authority to investigate and fine companies found to have poor security programs. In addition to fines, companies can be forced to pay for recurring, annual audits to demonstrate cybersecurity program effectiveness.
Below is a short list of statutory and regulatory requirements, as well as leading cybersecurity frameworks, that EXPECT every organization documents and maintains cybersecurity-related procedures. If you need to address one or more of those frameworks, then you need to maintain documented procedures.
- SOC 2
- CIS CSC 7
- Criminal Justice Information Services (CJIS)
- EU GDPR
- ISO 27001
- ISO 27002
- ISO 27018
- ISO 29100
- ISO 39100
- New Zealand Information Security Manual (NZISM)
- NIST Cybersecurity Framework
- NIST 800-53
- NIST 800-160
- NIST 800-171
- NY DFS 23 NYCRR 500
- PCI DSS
- UK Cyber Essentials
- UL 2900-1