No one likes writing policies and procedures or forensic reports, but such documentation plays a vital role in security architecture. They verify that your company takes appropriate measures to protect its information systems and data. In the event of a breach, that’s essential to prove regulatory compliance. Additionally, it helps the business receive appropriate compensation from any cyber insurance policies, and defend against legal actions from clients and business partners. Perhaps most importantly, the lessons they contain can help prevent future compromises.
What to Document
Many people new to cybersecurity wonder what they need to document as part of their Information Security Plan. It’s only a slight exaggeration to say, well, everything. The more data you collect about how you manage your information management needs and systems, the more clues you have if you do need to investigate a suspected incident. Many network management tools offer automatic logging of traffic. Remember, though, that IT personnel need to configure them properly and regularly review the resulting information for full effectiveness.
Additionally, you need to document the following elements of your security architecture and information management program:
Information System
Documenting your information system involves mapping hardware, software, data assets, and access protocols. For hardware, list the purchase date and anticipated service life of the device; nothing lasts forever, after all. You’ll want to track the location and function of all devices connected to the system. This should include any remote or employee-owned equipment. Serial numbers of similar identifiers can make this task much easier. You’ll also want to include the maintenance schedule and service history for the various components.
When it comes to software, it’s important to understand that companies rarely “own” programs unless they are proprietary ones created by in-house development teams or custom-built by a third-party vendor. Instead, businesses hold licenses allowing them to use applications for specific periods of time and/or under certain circumstances. Companies must be able to produce the appropriate license for every installation of an item of software. Additionally, many vendors now provide cloud-based access to their software, often on a subscription basis. In this case, the fee(s) and payment schedules need to be tracked, along with authorized user profiles. Lastly, it’s important to record the version numbers and update/patch installation histories for all installations.
WIth regard to data assets, you’ll want to document customer and transaction data, human resources data, financial data, and all forms of intellectual property. Then, you’ll want to list the level of access associated with these assets. You’ll also need to document the protocols for setting these access levels and for determining the access needs of both internal and external users.
Non-Public Information Privacy Controls
Privacy control needs and the requirements for documenting them can vary depending on where you do business. In recent years, a number of states passed legislation to protect consumers’ privacy. These laws govern the collection, storage, use, and disposal of consumer information, including biometric data. The kind of information stored — for example, data related to healthcare — may trigger additional requirements.
Generally speaking, however, you’ll want to document collection methods, uses for such information (especially sale to third parties), consent procedures, and disposal/deletion protocols.
Risk Assessment
Regular risk assessment is the foundation of your security architecture. After all, how can you be confident that your defenses are adequate if you’re not sure what they need to defend against? A robust risk assessment should identify key business processes and the resources required to complete them. It should list risks with their likelihood of occurrence and potential impact. It should also explain the business’ risk tolerance level and document risk mitigation resources. You’ll want to include the findings and recommendations from any external vulnerability assessments performed, as well. Remember, the risk assessment needs to include not only the control decisions but also an explanation of how they are made.
Information Security Program
All your safeguards and mitigation measures need to be documented in written policies and procedures. In the event of a regulatory audit or after an actual or suspected breach, you will be expected to provide both for review, along with any other records that document your (planned) response to a cyber event.
A policy describes your desired outcome and summarizes the measures you plan to take to achieve that outcome. For example, your policy for backing up data might go something like this:
To ensure continuous access to the data stored in our information systems, we will perform regular backups of our data and will secure a copy of such backups off-site. In the event that our primary systems are compromised, IT personnel will restore our data to a comparable system and ensure access for key personnel within 36 hours.
Procedures are much more detailed. The procedure supporting our sample backup policy, for example, might include information such as a list of backups made and step-by-step directions for how to run them, as well as the backup schedule and a roster of qualified personnel, among others.
If simulation exercises or penetration testing are a part of your ISP, document their methodology and outcomes as well.
Third-Party Vendor Oversight
In our increasingly interconnected world, it’s a rare business that doesn’t allow third-parties some access to its information or incorporate information provided by these parties into its own data set. Begin by mapping the data supply chain. Describe your data security standards for such parties and the procedures used to verify compliance with them. Finally, include the latest vendor assessment findings.
Employee Training
We’ve already discussed the vital role that employee training plays in your cybersecurity program. Documentation of such training should include a schedule of activities, describe the resources used, and list participants. If formal testing or simulation exercises are part of your program, include their results as well.
Incident Response Plan
Sadly, for most of us it’s not a question of if we’ll face a cybersecurity attack, but when. Your Incident Response Plan needs to document who will make decisions regarding the investigation of and response to a breach; internal processes for responding to a breach, including communication channels; and protocols for notifying regulators and affected parties. Include detailed reports of cybersecurity events, lessons learned, and how you’ll apply that knowledge to improve detection and response measures.
There’s currently some debate regarding whether documentation should include all suspected breaches or only confirmed events. This is the result of recent moves to limit the confidentiality of such reports.
Reports to Leadership
If executives don’t have a “hands-on” role in their company’s data security initiatives, those directly responsible for the program need to provide regular updates for their review and approval. In states that have adopted a version of the NAIC’s Insurance Data Security Model Law generally mandate such reporting at least annually.
The report should include the overall status of the Information Security Program (ISP) and the organization’s current compliance status, the findings of the most recent risk assessment and a summary of risk management and control decisions; the arrangements in place to monitor the risk assessments and mitigation efforts of third-party vendors; the results of penetration testing and other simulation exercises; reports on actual or suspected cybersecurity events/violations and the organization’s response to these events; and recommendations for further improving the effectiveness of the ISP.
How Often to Review
In some cases, federal or state regulations, cyber insurance “due care” requirements, or even terms of contracts may dictate the frequency for completing and documenting security activities. Typically, however, this sets a minimum requirement.
How often you actually need to revisit your security needs and measures depends on the volume and type of information you store, the value of that information, your organization’s threat tolerance level, how frequently information is accessed or changed, the evolution of cyber threats, and the rate of turnover among team members. Different types of documentation may also need to be reviewed on different cycles. Policies, for example, being more general in nature, won’t need to be re-visited as often as procedures, which need to continuously adapt to new technologies.
Document Retention
If all this sounds like it’s going to generate a LOT of very confidential information, it is. The question then becomes, how long should an organization hold onto such documents? From a regulatory standpoint, there’s not a lot of guidance – although many states do require licensees to maintain records concerning actual cybersecurity events for at least five years from the date of the event.
Generally, you’ll want to retain records until the statute of limitations for bringing criminal or civil suits arising from the events lapses. (How long that might be is a question for your attorney.) Of course, many organizations opt to retain all their records indefinitely. In that case, secure off-site storage is beneficial – if not essential.
As overwhelming as all this seems, it’s actually a pretty high-level view of your business’s documentation needs. Remember, too, that how you word your reports is often as important as what you document, especially when it comes to their evidentiary value. For more specific information, keep an eye out for future articles or contact ILSA’s collaborator for all things cybersecurity, RSI, for additional help.
This is the fourth in a series of articles discussing some of the most commonly overlooked aspects of security architecture and cybersecurity compliance. Other articles address email security, employee training and awareness, automated updates and patches, and notification and filing requirements.