Nobody really wants to do their homework.
Which is unfortunate, because homework plays an important role in helping to absorb, retain, and learn to use the information someone is studying.
In the security and compliance world, writing documentation is the homework. It helps employees standardize the right policies and procedures to successfully reduce risk and regularly practice activities needed for compliance.
Good SOC 2 compliance documentation is not created for its own sake, or just to tick a box for an audit. Good documentation is written to help organizations standardize their processes, scale their operations, and ingrain a strong security culture.
What makes good SOC 2 Compliance Documentation?
The short answer is this: document your processes and policies as you are actually practicing them. Don’t make them aspirational.
If you feel that a process or practice in place at your business is not good enough for SOC 2, take that as a sign to improve it, then document it!
SOC 2 isn’t a set of hard and fast rules. It is a framework that helps you prioritize security, availability, processing integrity, confidentiality and privacy. Documentation is a key part of achieving this.
It is never too early to get your documentation in order! Documenting policies and processes takes a significant amount of time when preparing for a SOC 2 audit. Why not start now?
Having your processes documented will improve consistency and internal communication, serve as a training tool and help protect your organization from possible legal action or employee fraud.
There are many policy templates out there. Most are a challenge to use.
One of the better ones is from the Center for Internet Security (CIS). They provide a free set of policy templates mapped to the NIST Cybersecurity Framework (CSF). Even though these are “better” they are still challenging. You will need dozens or hundreds of hours to completely customize a set of policies for your organization.They must become something your organization will actually use.
To get started, figure out where your biggest gaps are first – this ensures your earliest efforts have the biggest impact. Then, grab a template, read up on our suggestions on what to include, and get editing.
Generally, for SOC 2, these are the policies you must have/comply with:
1. Information Security Policy
Password Policy
Email Policy
Laptop Policy
Bring Your Own Device (BYOD) Policy
2. Operational Security Policy
Operational Security Policy
Logging and Monitoring Policy
Vulnerability and Patch Management Policy
Change Management Policy
Access Control Policy
Encryption Policy
Backup and Retention Policy
3. Data Classification and Handling Policy
4. Incident Response Policy
5. SDLC Policy
6. Risk Management Policy
7. Vendor Management Policy
8. Business Continuity and Disaster Recovery Policy
9. Acceptable Use Policy
10. Internal Audit Policy
11. Privacy Policy
12. Whistleblower Policy
SOC 2 Procedures :
Internal Audit Plan/Procedure
Incident Response Plan
Business Continuity/Disaster Recovery Plan
Vendor Assessment Procedure
Onboarding and Offboarding Procedure
How to create policies for SOC 2 compliance
The above list is a suggested way to divide up the policies. But these don’t all have to be separate documents.
As long as these topics are covered, you can document them based on your viewership and ownership (of the process) however you get the best value out of it.
An organization with an internal IT team may find it valuable to include the Internal Audit Policy in their Operational Security Policy, because the implementation of the policy is controlled by the same owner.
On the other hand, another organization may have it separate because the operational security is implemented by a Managed Service Provider and the audit and accountability falls on an internal one-person IT team.
It may make sense for your organization to have separate a Risk Management Policy and Vendor Management Policy because it is your COO’s job to own and manage risk and the Vendor Procurement Specialist’s job to manage vendors.
If an organization has a separate Risk Committee that overlooks both – the vendor risk management and overall risk management for the organization – you may want to merge these policies. The Internal Audit, Risk Management, Vendor Management Policies can all go under Operational Security Policy if that works for your viewers and owners.
Ultimately, there is no right or wrong in how to organize your SOC 2 compliance documentation – as long as all the topics are covered.
Your goal is to provide all the context and information viewers will need to understand the policy. This will help you create comprehensive SOC 2 compliance documentation and help your reader understand the facts better.
All policies should have the following questions clearly defined in the beginning of each document:
Purpose – What is the policy trying to achieve? What are the goals of the document?Audience – To whom the policy applies? What is acceptable behavior? What disciplinary action will they face if they don’t abide by it?Scope – How and when the policy applies? What activities does it cover?Revisions and Approvals- Who has authorized this document? When was the last time the policy was updated? What was changed? Who made the changes?
Maintenance – How often should the policy be reviewed?Exceptions – Who should be contacted if there arises a circumstance in which it will not be possible to follow the policy? Who should be contacted with enquiries or complaints relating to the policy?
Some additional sections that may need to be included in –
Definitions – If the policy includes terms that may not be immediately understood by the audience, they should be clearly defined in this section early in the document.Roles and Responsibilities – What are some specific roles that are assigned for the enactment or enforcement of the policy?Reference – Are there any other related policies or documents mentioned in the policy? Are there government regulations or industry governing bodies mentioned in the policy? (Tip: Provide links to all other referenced documents, including other policies, regulations, and procedures.)
Besides compliance, what do policies and procedures provide an organization?
Policy and procedure documentation provides a roadmap for day-to-day operations. Keep in mind these documents will provide guidance and instructions on how to deal with a situation or complete a specific task.
1. Information Security Policy
The information security policy is an outline for management and administration of overall security in the organization. All employees must review and sign off on this policy. Areas frequently covered in the information security policy include:
Network security
Email policy
Password management and MFA
Laptop security
Bring Your Own Device (BYOD)/Mobile Device policy
Security awareness training
Reporting security issues
Engaging a vendor or service
2. Operational Security Policy
This operational security policy is for the IT and/or Engineering teams. It provides them with a clear understanding of the key operational security functions that should be performed to maintain security in the organization. The policy should clearly define who is responsible for what. Key sections to include in this policy:
Access Control (physical and logical)
Asset and inventory management
Patch Management
Vulnerability Management
Change Management (internal IT/corporate)
Network Security (if needed)
Encryption Policy
Logging and Monitoring
Data Deletion and Equipment Disposal
Security awareness training management
3. Data Classification and Handling Policy
The data classification and handling policy establishes a framework for classifying data based on its sensitivity, value and criticality to the organization. Everyone needs to know how data is classified and should be protected, hence, this policy should be distributed to all employees and contractors. Additionally, it provides guidelines on how to handle different levels of data, including sharing, requesting, retaining, deleting.
4. Incident Response Policy
The objective of the incident response policy is to ensure there is a consistent and effective approach to managing and responding to security incidents.
It should clearly define what constitutes an incident, breach or exposure. It should also document compliance and regulatory considerations. Additionally, there should be a commitment from management and prioritization of goals in the event of an incident (Human life > Business Continuity > Productivity).
5. SDLC Policy and Change Management Policy
An SDLC policy should help establish a relationship between each stage of the development process. The audience of this policy is application and infrastructure developers, program/project managers, engineering team and other project stakeholders. The policy should cover:
Creation of Code,
Committing Changes,
Monitoring and Reviewing
Access to code
Analysis of code
Documentation,
Emergency Changes
6. Risk Management Policy
This risk management policy should establish a formal framework for your organization’s risk management program and designate responsibilities for risk identification, analysis and planning for risk handling.
The idea is to provide guidance around managing risks to support corporate objectives and protect business assets and staff along with maintaining financial stability. The policy must talk about risk identification, estimation and treatment, and will typically be supported by a risk register.
7. Vendor Management Policy
A good vendor management program will help your organization identify and prioritize the risks that different vendors pose to the business. A Vendor Management Policy guides this program by setting guidelines for due diligence for vendors and contractors, granting access to sensitive information and assets, and managing third-party risks. It should define responsibilities for managing vendor relationships, and communication paths with vendors in case of emergencies.
8. Business Continuity and Disaster Recovery Policy
The business continuity and disaster recovery policy intends to provide guidance in the event of a service disruption or disaster triggering the need for business contingency and continuity. The focus is on critical business processes that directly impact your customers in the operation and support of your services.
This policy defines the roles and responsibilities of participants, characterization of incidents, relationships to other policies and procedures, and reporting requirements.
9. Acceptable Use Policy
The acceptable use policy must be reviewed by every employee in the organization. It lays out the rules when it comes to use of company equipment, systems and information. The policy should cover:
General use and ownership,
System and network activities
Handling proprietary information
Internet, email and communication activities
Social media use
10. Whistleblower Policy
SOC 2 emphasizes communication, both internal and external (COSO Principle 14 and 15). Part of proving that your organization is committed to ethical communication is having a Whistleblower Program in place so users (internal and external) can report internal issues, potential fraud, and can do so anonymously – without fear of retaliation.
11. Internal Audit Policy
Internal audits are required for SOC 2 compliance. The internal audit policy sets a framework for audit functions that oversee internal policies and procedures to ensure that they are operating effectively. More importantly, it makes sure that your organization is following its policies.
The internal audit policy should define and establish the responsibilities of the internal audit function and how to deal with the findings.
The audit should cover access, change, patching and vulnerability management, logging and monitoring, employee onboarding and offboarding vendor reviews, everything. Set expectations (responsibilities, frequency, reporting, follow ups) for the audit of all controls and processes established for your organization’s security program.
12. Privacy Policy (When privacy is in scope)
A privacy policy should document how your organization (or website) collects stores, protects and uses personal information provided by the users. This policy should be publicly available on your website.
List of SOC 2 Procedures
A number of important security procedures must covered in your SOC 2 compliance documentation.
If you’re wondering how to differentiate between procedures and policies, this is a good guideline: Policies look at the big picture, think of them as mini mission statements. Meanwhile, procedures are detailed actions for individual processes, they are helpful for the implementation of programs.
1. Internal Audit Plan/Procedure
The internal audit plan provides a schedule that explains how your organization intends to monitor the internal controls over the course of a year (or longer). The plan should detail which control you are monitoring, how frequently it is tested and what you are testing (on a high level) to establish the control’s effectiveness.
2. Incident Response Plan
The incident response plan is an extremely important document – even outside of SOC 2!
The plan needs to define the team structure, availability, and roles. Include MSPs, any outside resources like insurance provider, 3rd party incident coach, and your legal team. Everyone’s contact information must be listed.
The plan should detail the approach for all four phases of managing an incident:
1. Preparation – Include the team contacts, communication guide, logging and monitoring controls, evidence preservation techniques, severity ratings, notification threshold, and insurance coverage information.
2. Detection + Analysis – What are the symptoms to look for in your systems? Common detection points include: a notification from an intrusion detection tool, suspicious logs, repetitive unsuccessful login attempts within a short time, poor system performance or resource consumption of servers, etc.
To determine the scope and severity of an incident consider how many systems/accounts were affected? Was there any confidential or protected information involved?
3. Containment + Eradication + Recovery – The objective of the containment step is to prevent further damage, remove the threat, and return to normal operations.
When evaluating containment steps, think about how you can reduce the impact. If the ability to provide critical services will be impacted, the resources that would be required to support the containment activities, when should your insurance carrier be notified, does any evidence need to be preserved.
In the eradication phase, breached user accounts should be disabled, active sessions reset, ports closed, patches applied, account passwords changed.
To restore systems and return to a normal environment, consider how long it would take? Have the systems been patched, hardened and tested? What tools/configurations will ensure that a similar attack will not reoccur?
4. Post Incident Activity – Once investigations have been completed, a post-incident meeting is crucial to discuss what the team learned from the incident.
Include questions in the plan to guide this activity:
What changes need to be made to security?
How can employees be trained differently?
What weakness did the incident exploit?
How can the team ensure that a similar incident doesn’t happen again?
There are a number of other questions you must answer within your incident response plan. Ask yourself the following:
When will you involve cyber insurance?
When will you involve an external forensics team and law enforcement? Who will interface with them?
What are your regulatory requirements?
3. Business Continuity/Disaster Recovery Plan
The business continuity/disaster recovery plan may be one combined document or break each element out into its own. The plans should include contingencies and communication guidelines in case of emergencies, such as a natural disaster. Take into account the type of workforce (remote or hybrid), your service types (both operational and production).
The plan (or procedure) should answer questions like:
How to perform recovery of critical service for the office?
Identify critical services for internal operations and production/service delivery and have a backup and restoration plan for each
What steps should be followed when a vendor is down? What are alternatives?
When to communicate with internal and external parties? Who should communicate? How should communications be sent out?
The transition from on-premise to remote/hybrid work over the last few years has had a dramatic impact on BC/DR plans. View the linked guide for tips on how to update for remote-first or hybrid workforces.
4. Vendor Assessment Procedure
Design this process document to help your team evaluate and onboard new vendors. It could be as simple as a checklist. The level of scrutiny in a vendor review should be based on the type of information each vendor has access to and the impact the vendor would have on your organization’s ability to provide service to your customers and clients. This procedure will be a key part of your vendor risk management program . Include in the process:
Document collection
Availability concerns
Identify a business owner
SSO/MFA support
Does this vendor need to be added to the offboarding checklist?
Consider impact on BC/DR
5. Onboarding and Offboarding Procedure
This is a key part of access control. It is essential to make sure that a proper screening and approval process is followed before granting access to facilities and sensitive information. The offboarding checklist is to help your organization minimize risk during employee exit.
Key things to include in the onboarding checklist:
Background check
NDA/confidentiality agreement
Policy acknowledgement
Security awareness training
Key things to include in the offboarding checklist:
Remove access to systems and data
Devices returned?
Keys returned?
Password rotation (if and as required)
6. Other Documents
Other than the policies and procedure documents, you also need some operational documents for a SOC 2 audit. This includes:
Data flow diagram that captures how data flows in and out of your systems. This one is a requirement for the Processing Integrity principle.
Network diagrams and architecture diagrams that lay out how different systems and elements are connected. Keep in mind to not include sensitive details in such diagrams.
Organizational chart(s) that shows the breakdown of the org structure and the relationships between personnel and departments. This chart will also prove to the auditors that there is an understanding of the roles and responsibilities along with segregation of duties.
Backup schedule and Data retention process/timeline to document the systems that are backed up, frequency of backups, and retention plans.
Restoration procedure is part of the BC/DR plan and policy. This document should ensure step by step instructions are available to use when data is lost or damaged. It is also wise to test this procedure from time to time and make amends if necessary.
Risk assessment process that lays down the systematic process for identifying, analyzing, communicating and controlling risks. Include how the organization assesses fraud too.
SOC 2 Compliance Documentation Isn’t just for Compliance
Often, SOC 2 compliance documentation is viewed as a checklist item, like doing a homework assignment for a subject you don’t like or are not interested in. But you’re supposed to do your homework! It makes you more well-rounded.
Writing policies and documenting your procedures won’t magically fix all your security problems, but creating effective, usable documents will certainly improve your chances of success: not only in the SOC 2 audit, but also your overall business security growth.
Want to get great cybersecurity content delivered to your inbox? C lick here to sign up for our monthly newsletter, Tales from the Click.
