Table of content
- 1. ASSET MANAGEMENT POLICY
- 2. ACCEPTABLE USE POLICY
- 3. BACKUP POLICY
- 4. CODE OF CONDUCT
- 5. DATA DELETION POLICY
- 6. DATA PROTECTION POLICY
- 7. DISASTER RECOVERY PLAN
- 8. INFORMATION SECURITY POLICY
- 9. PASSWORD POLICY
- 10. PHYSICAL SECURITY POLICY
- 11. RESPONSIBLE DISCLOSURE POLICY
- 12. SOFTWARE DEVELOPMENT LIFE CYCLE POLICY
- 13. SYSTEM ACCESS CONTROL POLICY
- 14. VENDOR MANAGEMENT POLICY
- 15. VULNERABILITY MANAGEMENT POLICY
- 16. ENCRYPTION POLICY
- 17. BUSINESS CONTINUITY PLAN
- 18. DATA CLASSIFICATION POLICY
- 19. INCIDENT RESPONSE
- 20. RISK ASSESSMENT POLICY
Last updated August 17, 2022
1. Asset Management Policy
SOC 2 Criteria: CC2.1, CC6.1
ISO 27001 Annex A: A.6.1.1, A.8.1.1, A.8.1.2, A.8.1.4, A.8.2.3, A.8.3.1, A.8.3.2, A.8.3.3, A.11.2.7, A.12.1.1, A.12.1.3, A.12.6.1, A.13.2.2
Keywords: Asset Inventory, Asset Ownership, Anti-Virus, Network Diagram, Hardening Standards, Handling Assets, Media Management and Transfer
The purpose of this policy is to define requirements for mapping and properly tracking assets owned, managed, and under the control of Collate through their lifecycle from initial acquisition to final disposal.
Roles and Responsibilities
- The CTO and Security Team are responsible for updating, reviewing, maintaining, and enforcing this policy and all statements within this policy.
Physical and Virtual Asset Standard
Collate will ensure the proper management of assets to maximize information security. The following procedures will be enforced as applicable to Collate assets to ensure proper maintenance, tracking, monitoring, and handling of assets:
- A detailed asset inventory will be maintained to track and monitor assets.
- All significant assets will be accounted for on the inventory.
- Items can be excluded from the inventory if they carry very low purchase/replacement costs (including time and labor needed to install and configure) and pose little or no risk to business operations or compliance status.
- Each significant asset will be associated with an identifier, license, or tag, and proper classification when applicable.
- Details should include a description of the type of asset, the make/model of the asset, technical specifications, license details, and versions of the software packages or operating systems.
- Assets that contain, store, or handle information, will be classified per the Data Classification Policy.
- All copies of media assets will be clearly marked for the attention of the authorized recipient.
- Temporary or permanent copies of information will be at a level consistent with the protection of the original information.
- Access to each asset will be restricted based on the asset’s classification.
- A record of authorized recipients of assets will be established and maintained.
- The disposal/replacement of physical and virtual assets will be tracked, whether it is due to depreciation, expiring leases or agreements, obsolescence/end of support, loss, or other reasons.
- A reporting function will support auditing and monitoring for IT compliance with this standard.
Asset Inventory Standard
An asset inventory process must be in place to support the technological management of critical business processes and to meet legal and regulatory requirements. The inventory process will also support the discovery, management, and replacement/ disposal of all assets. It will further facilitate the identification and removal of any illegal or unauthorized software, asset, or processes found in the Collate environment. To accomplish these goals, all physical and virtual assets under Collate management or control will be listed in an inventory that will include:
- Unique identifier or name of the asset
- Description of the asset
- Purpose of the asset and the role the asset has in supporting critical business processes and in meeting legal or regulatory requirements, if applicable
- The entity responsible for the asset
- Classification of the asset, if applicable, as prescribed in the Data Classification Policy
Collate will assign an owner to each asset when the asset is created or transferred to Collate. The asset owner can be an individual or an entity with approved management responsibility to control the whole lifecycle of the asset; the asset owner will not necessarily have property rights to the asset.
The asset owner will be responsible for the proper management of the asset over the asset’s entire lifecycle, or until a new owner is assigned to the asset. The asset owner will:
- Ensure that assets are inventoried.
- Ensure that assets are appropriately classified and protected.
- Define and periodically review access restrictions and classification of important assets, taking into account applicable access control policies.
- Ensure proper handling when the asset is deleted/destroyed.
Physical Asset Inventory
Collate leverages a SaaS-based asset management system, Drata, to maintain inventory of all company-owned physical computing equipment, including but not limited to:
- Networking equipment
All company-owned devices are subject to a complete data wipe if deemed necessary, such as in the case of device infection or repurposing. This data wipe will be carried out by the IT manager.
Asset Retirement Standard
The information resource owner determines when an asset no longer is needed or is obsolete and can be retired. If the asset to be replaced/retired supports mandatory legal and regulatory requirements of critical business processes, the information resource owner must ensure that any replacement asset can support these processes before the current asset is retired.
Before retiring/replacing any asset that retains data, data retention requirements for all data stored or managed by that asset must be reviewed, and a plan for complying with all applicable data retention requirements must be developed and executed. This is particularly important for assets that manage data subject to legal/regulatory scrutiny. Any data subject to data retention requirements must be migrated to an appropriate destination and tested for appropriateness, completeness, accessibility, and retrievability from the destination before the original data is deleted from the original asset as part of the asset retirement process.
System Hardening Standards
Device Best Practices and Hardening Standards
- Manufacturer-provided hardening and best practice guides will be employed to ensure all device installation is properly guarded against vulnerabilities and unauthorized attempts to access the systems.
- Center for Internet Security (CIS) benchmarks are utilized where possible for system hardening guidance. (https://www.cisecurity.org/cis-benchmarks/)
- Vendor-supplied defaults, including usernames, passwords, and any other common settings that may result in unauthorized attempts to access the systems, will be changed in accordance with hardening guides.
- Insecure and unnecessary communication protocols are disabled.
- Local passwords, when required, will be randomly generated and securely stored in the approved password management system.
- Current patches will be installed.
- Malware protection will be implemented.
- Logging will be enabled.
- Two-factor authentication should be used whenever available/supported on the device platform.
Infrastructure Configuration and Maintenance
- Internal Workstation and Server Patching
- Operating system patches/upgrades are evaluated periodically.
- Operating system and security patches/upgrades are installed based on their criticality.
- Operating system patches/upgrades are installed during off-peak hours to minimize the disruption to business processes.
- Internal Infrastructure Patching
- Infrastructure (routers, switches, virtual hosts, etc.) patches/upgrades are evaluated as they come available from vendors.
- Infrastructure patches/upgrades are installed based on their criticality.
- Infrastructure patches/upgrades are reviewed and approved via a lab environment when possible/practical.
- Infrastructure patches/upgrades are installed during off-peak hours to minimize the disruption to business processes.
- When applicable, redundant systems are patched/upgraded one device at a time to ensure no impact on shared services.
- Networking hardware/software updates follow the regular change management procedures.
- Infrastructure Support Documentation
- A network diagram is available to all appropriate service personnel and is kept current.
- Configuration standards for the setup of all infrastructure devices are in place and are formally documented as necessary.
- Endpoint Security/Threat detection
- Controls are in place to restrict the use of removable media to authorized personnel
- Antivirus and anti-malware tools are deployed on end-point devices (e.g., workstations, laptops, and mobile devices).
- Antivirus and anti-malware tools are configured to automatically receive updates, run scans and alert appropriate personnel of viruses or malware.
Capacity requirements of systems will be identified in line with the business criticality of a concerned system.
- System tuning and monitoring will be applied to ensure and improve (when needed) the availability and efficiency of systems.
- Detective controls will be put in place to indicate problems as they occur.
- Projections of future capacity requirements will account of new business and system requirements and current and projected trends in the company’s information processing capabilities.
- To mitigate bottlenecks and dependence on key personnel presenting a threat to system security or services, managers must monitor the utilization of key system resources, identify trends in usage, and account for any resources that may have a long procurement lead times or high costs.
Providing sufficient capacity will be achieved by increasing capacity or by reducing demand. This includes:
- Deletion of obsolete data (disk space)
- Decommissioning of applications, systems, databases, or environments
- Optimizing batch processes and schedules
- Optimizing application logic or database queries
- Denying or restricting bandwidth for resource-hungry services if these are not business- critical (e.g. video streaming)
- Managing capacity demand
- Provisioning new server instances when capacity thresholds are met
Management of Media Removable Media
For the proper management of removable media, the following steps will be taken, when applicable:
- Authorization will be required for removing media from Collate facilities or assets, when necessary and practical.
- A record of the removal will be kept for an audit trail
- Contents of any reusable media being retired, or replaced, will be made unrecoverable.
- All media will be stored and secured in accordance with manufacturers’ specifications.
- Cryptographic techniques should be used to protect data on removable media to maintain integrity and confidentiality.
- Media degradation will be mitigated by transferring stored data to fresh media before becoming unreadable.
- Coincidental data damage or loss will be mitigated by making multiple copies of valuable data on separate media.
- Removable media drives will only be enabled if there is a business reason for it.
- Transfer of information to removable media will be monitored.
Physical Media Transfer
For the protection of media containing information during transport, the following steps will be taken, when applicable:
- Reliable transport/couriers will be used.
- Management-approved list of authorized couriers
- Procedures to verify the identification of couriers
- Packaging of media will be sufficient to protect the contents from any physical damage during transport and in accordance with any manufacturers’ specifications
- Transfers will be logged with information
- Information about the content of the media
- Type of protection applied
- Time of transfer to transport custodian
- Time of receipt at destination
Return of Assets Upon Termination
- The termination process includes the return of all previously issued physical and electronic assets owned by or entrusted to Collate, as outlined in the Employment Terms and Conditions, and Asset Management Policy.
- If Collate equipment was purchased by an employee or third party user, or personal equipment was used, all relevant information must be transferred to Collate and securely erased from the equipment.
- Unauthorized copying of the information by employees and contractors will be monitored and controlled during the termination period.
Disposal of Media
The steps for the secure disposal of media containing confidential information will be proportional to the sensitivity of that information. The following guidelines will be applied accordingly:
Identification of items that require disposal.
- Use of appropriate third-party collection and disposal services in accordance with the Vendor Management Policy.
- Secure disposal by incineration or shredding, or erasure of data for use by another application within the company.
- Risk assessment of damaged media to determine disposal or repair.
- Whole-disk encryption to mitigate risk of disclosure of confidential information, in line with Collate Encryption Policy.
- Logging each disposal to maintain an audit trail.
2. Acceptable Use Policy
SOC 2 Criteria: CC1.1, CC1.4, CC1.5, CC2.2, CC5.2 ISO 27001 Annex A: A.8.1.3, A.11.2.9, A.12.2.1, A.12.6.2
Keywords: Background Checks, Security Awareness Training, Hard Drive Encryption, Anti-Virus Software
Collate is committed to ensuring all workforce members actively address security and compliance in their roles at Collate. We encourage self-management and reward the right behaviors.
This policy specifies the acceptable use of end-user computing devices and technology. Additionally, training is imperative to assure an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non-compliance.
Roles and Responsibilities
The CTO and Security Team are responsible for updating, reviewing, maintaining, and enforcing this policy and all statements within this policy.
Collate policy requires all workforce members to accept and comply with the Acceptable Use Policy. Collate policy requires that:
- Background verification checks on all candidates for employees and contractors should be carried out in accordance with relevant laws, regulations, and ethics, and proportional to the business requirements, the classification of the information to be accessed, and the perceived risk.
- Employees, contractors, and third-party users must agree to and sign the terms and conditions of their employment contract, and comply with acceptable use.
- Employees will go through an onboarding process that familiarizes them with the environments, systems, security requirements, and procedures Collate has in place. Employees will also have ongoing security awareness training that is audited.
- Employee offboarding will include reiterating any duties and responsibilities still valid after terminations, verifying that access to any Collate systems has been removed, as well as ensuring that all company-owned assets are returned.
- Collate and its employees will take reasonable measures to ensure no corporate data is transmitted via digital communications such as email or posted on social media outlets.
- Collate will maintain a list of prohibited activities that will be part of onboarding procedures and have training available if/when the list of those activities changes.
- A fair disciplinary process will be utilized for employees that are suspected of committing breaches of security. Multiple factors will be considered when deciding the response, such as whether or not this was a first offense, training, business contracts, etc. Collate reserves the right to terminate employees in the case of serious cases of misconduct.
Collate requires all workforce members to comply with the following acceptable use requirements and procedures, such that:
- All workforce members are primarily considered to be remote users and therefore must follow all system access controls and procedures for remote access.
- Use of Collate computing systems is subject to monitoring by Collate IT and/or Security teams.
- Employees may not leave computing devices (including laptops and smart devices) used for business purposes, including company-provided and BYOD devices, unattended in public.
- Device encryption must be enabled for all mobile devices accessing company data, such as whole-disk encryption for all laptops.
- All email messages containing sensitive or confidential data will be encrypted.
- Employees may not post any sensitive or confidential data in public forums or chat rooms. If a posting is needed to obtain technical support, data must be sanitized to remove any sensitive or confidential information prior to posting.
- All data storage devices and media must be managed according to the Collate Data Classification specifications and Data Handling procedures.
- Employees may only use photocopiers and other reproduction technology for authorized use.
- Media containing sensitive/classified information should be removed from printers immediately.
- The PIN code function will be used on printers with such capability, so that the originators are the only ones who can get their print-outs and only when physically present at the printer.
Protection Against Malware
Collate protects against malware through malware detection and repair software, information security awareness, and appropriate system access and change management controls. This includes:
- Anti-malware or equivalent protection and monitoring must be installed and enabled on all endpoint systems that may be affected by malware, including workstations, laptops, and servers. Regular scans will include:
- Any files received over networks or via any form of storage medium, for malware before use;
- Electronic mail attachments and downloads for malware before use; this scan should be carried out at different places, e.g. at electronic mail servers, desktop computers, and when entering the network of the organization;
- Web pages for malware.
- Restrictions on Software Installation
- Only legal, approved software with a valid license installed through a pre-approved application store will be used. Use of personal software for business purposes and vice versa is prohibited.
- The principle of least privilege will be applied, where only users who have been granted certain privileges may install the software.
- Collate will identify what types of software installations are permitted or prohibited.
- Controls that prevent or detect the use of unauthorized software (e.g. application whitelisting)
- Controls that prevent or detect the use of known or suspected malicious websites (e.g. blacklisting)
- Vulnerabilities that could be exploited by malware will be reduced, e.g. through technical vulnerability management.
- Collate will conduct regular reviews of the software and data content of systems supporting critical business processes; the presence of any unapproved files or unauthorized amendments should be formally investigated.
- Malware detection and repair software will be installed and regularly updated to scan computers and media as a precautionary control, or on a routine basis; the scan carried out will include:
- Any files received over networks or via any form of storage medium, for malware before use;
- Electronic mail attachments and downloads for malware before use; this scan should be carried out at different places, e.g. at electronic mail servers, desktop computers, and when entering the network of the organization;
- Web pages for malware.
- Defining procedures and responsibilities to deal with malware protection on systems, training in their use, reporting, and recovering from malware attacks.
- Preparing appropriate business continuity plans for recovering from malware attacks, including all necessary data and software backup and recovery arrangements.
- Implementing procedures to regularly collect information, such as subscribing to mailing lists or verifying websites giving information about new malware.
- Implementing procedures to verify information relating to malware, and ensure that warning bulletins are accurate and informative; managers should ensure that qualified sources, e.g. reputable journals, reliable Internet sites, or suppliers producing software protecting against malware, are used to differentiate between hoaxes and real malware; all users should be made aware of the problem of hoaxes and what to do on receipt of them.
- Isolating environments where catastrophic impacts may result.
3. Backup Policy
SOC 2 Criteria: CC9.1, A1.2
ISO 27001 Annex A: A.5.1.1, A.8.3.1, A.12.1.1, A.12.3.1
Keywords: Multiple availability zones, Backup frequency
To protect the confidentiality, integrity, and availability of data, both for Collate and Collate’s customers, complete backups are performed daily to assure that data remains available when it’s needed and in the case of a disaster.
Collate policy requires that:
- Data should be classified at the time of creation or acquisition according to the Data Classification Policy
- All business data should be stored or replicated into a company-controlled repository
- Data must be backed up according to its level defined in Data Classification Policy.
- Data retention period must be defined and comply with any and all applicable regulatory and contractual requirements. More specifically,
- Data and records belonging to Collate customers must be retained per Collate product terms and conditions and/or specific contractual agreements.
- By default, all security documentation and audit trails are kept for a minimum of 1 year, unless otherwise specified by Collate’s Data Classification Policy, specific regulations, or contractual agreement.
Backup and Recovery Customer Data
Collate stores customer data in a secure production account in AWS using a combination of RDS databases. By default, S3 provides durable infrastructure to store important data and is designed for the durability of 99.99% of objects.
Collate performs automatic backups of all customer and system data to protect against catastrophic loss due to unforeseen events that impact the entire system. An automated process will back up all data to a separate zone in the same country (e.g. US East to US West). By default, data will be backed up Daily. The backups are encrypted in the same way as live production data. Backups are monitored and alerted by AWS Cloudwatch. Backup failures trigger an incident by alerting the Security Officer.
Collate stores its source code in git repositories hosted by Github. Source code repositories are backed up to Collate’s AWS S3 account on a daily basis. In the event that Github suffers a catastrophic loss of data, source code will be restored from the backups in AWS S3.
4. Code of Conduct
SOC 2 Criteria: CC1.1, CC1.4, CC1.5, CC2.2, CC5.3
Keywords: Ethical Behavior, Safety, Harassment, Disciplinary Action, Law Enforcement
The Collate Code of Conduct (“Code”) is built around our belief that everything we do will be measured against the highest possible standards of ethical business conduct. Our commitment to high standards helps us hire great people, build great products, and attract loyal customers.
Who must follow the Code?
We expect all employees to know and follow the Code. Failure to do so can result in disciplinary action, up to and including termination of employment. We also expect our contractors, consultants, and others who may be temporarily assigned to perform work or services for Collate to follow the Code when they work with us. Failure of a Collate contractor, consultant, or other service provider, to follow the Code can result in termination of their relationship with Collate.
Who to ask about the Code?
If you have a question or concern about the Code, be proactive and contact your manager. You can also submit a question or raise a concern regarding a suspected violation of our Code (or any other Collate policy) to your manager.
Collate prohibits retaliation against anyone who reports, or participates in an investigation of, a possible violation of our Code, our policies, or the law. Please contact a member of senior management if you believe that you are the subject of retaliation within Collate.
Code of Conduct
As a Collate employee, you’re expected to be honest, act ethically, and demonstrate integrity in all situations. You have a duty to follow policies and procedures found in this Code of Conduct, as well as those that are specific to your job. You must also comply with all laws that apply to our business. Most of the time, common sense and good judgment provide excellent guideposts. If you’re unsure about the right thing to do, ask someone on the management team.
Before you act, ask yourself:
- Is this the right thing to do?
- Is it legal?
- Do I have the authority to act?
- Does the action comply with the Code of Conduct and policies and procedures?
- If this action became public, how would it look in the news media?
- Would I be upset or embarrassed if other people found out about this action?
If your answer to any of these questions raises doubts, talk with your supervisor, anyone in management, or the Collate Compliance Officer. If you’re a supervisor or a manager, you’re responsible for knowing the rules and reviewing the Code of Conduct with the people who report to you to make sure they’re familiar with its contents. You’re also responsible for preventing violations of the Code, as well as detecting violations that may occur and reporting them appropriately.
You’re expected to:
- Lead with integrity.
- Encourage employees to ask questions and expand their knowledge of the rules.
- Demonstrate integrity by acting promptly and effectively when necessary.
- Educate employees on compliance policies specific to their job responsibilities.
Quality Work Environment
We are committed to a supportive work environment, where our employees have the opportunity to reach their fullest potential. Members of our Collate team are expected to do their utmost to create a workplace culture that is free of harassment, intimidation, bias, and unlawful discrimination. Please read the Employee Handbook for greater detail about how we should conduct ourselves at work.
Equal opportunity employment
Employment at Collate is based solely upon individual merit and qualifications directly related to professional competence. We strictly prohibit unlawful discrimination or harassment on the basis of race, color, religion, veteran status, national origin, ancestry, pregnancy status, sex, gender identity or expression, age, marital status, mental or physical disability, medical condition, sexual orientation, or any other characteristics protected by law. We also make reasonable accommodations to meet our obligations under laws protecting the rights of the disabled.
Harassment, discrimination, and bullying
Collate strictly prohibits discrimination, harassment, and bullying in any form – verbal, physical, or visual. If you believe that you’ve been bullied or harassed by anyone at Collate, or anyone connected to Collate (such as a partner or vendor), please immediately report the incident to your manager or the HR team. HR will promptly and thoroughly investigate any complaints and take appropriate action.
Drugs and alcohol
Substance abuse is incompatible with the health and safety of our employees, and we don’t permit it. Consumption of alcohol is allowed at our office on special occasions, but we ask everyone to use good judgment and never drink in a way that: (i) leads to impaired performance or inappropriate behavior, (ii) endangers the safety of others, or (iii) violates the law. Illegal drugs in our offices or at work-related events are strictly prohibited.
We are committed to a violence-free work environment. We will not tolerate any level of violence or the threat of violence in the workplace. No one should bring a weapon to work under any circumstances. If you become aware of a violation of this policy, report it to a member of senior management immediately.
Avoid conflicts of interest
As Collate employees, we should avoid conflicts of interest and circumstances that reasonably present the appearance of a conflict of interest, especially if it would create an incentive for you or present the appearance of an incentive for you, (whether directly or indirectly).
Here is list of areas where conflicts of interest often arise:
- Personal investments (e.g. with competitors)
- Outside employment, advisory roles, and board seats
- Business opportunities found through your work at Collate
- Inventions influenced by your work at Collate
- Business opportunities involving friends and relatives
- Acceptance of gifts, entertainment, and other business courtesies
If you are unsure if there is a conflict of interest, contact the Compliance or Legal teams to discuss.
Throughout its lifecycle, all nonpublic information that is processed, transmitted, and/ or stored
by Collate must be protected in a manner that is consistent with our contractual and legal requirements and reasonable and appropriate for the level of sensitivity, value, and risk associated with Nonpublic information (please see the Data Classification Policy). Information that contains data elements from multiple classifications must be protected at the highest level of information represented. For example, a document that contains Nonpublic and Public information must be treated as Nonpublic information. Nonpublic information must be secured against disclosure, modification, and access by unauthorized individuals. Therefore, the information must be:
- Secured at rest; and
- Secured in transit; and
- Securely destroyed in accordance with record retention policies and procedures.
You’re responsible for using Collate’s computer resources properly – especially with regard to information security – and you need to be thoroughly familiar with Collate’s Information Security policies and procedures.
These steps can go a long way in preventing unauthorized access:
- Never share your login information.
- Lock your workstation when you step away.
- Log off your workstation when you leave for the day.
- Clear your workstation, waste can, printers and fax machines of sensitive information, such as PII or company-sensitive information.
Protect Collate’s Assets
Collate’s intellectual property rights (e.g. patents, trademarks, copyrights, trade secrets, and “know-how”) are valuable assets. Unauthorized use can lead to their loss or serious loss of value. You must comply with all intellectual property laws, including laws governing the fair use of copyrights and trademarks. You must never use Collate’s trademarks or other protected information or property for any business or commercial venture without pre-clearance from the Marketing team. Report any suspected misuse of trademarks or other Collate intellectual property to the Legal or compliance team.
Likewise, respect the intellectual property rights of others. Inappropriate use of others’ intellectual property may expose Collate and you to criminal and civil fines and penalties. Seek advice from the Legal team before you solicit, accept, or use proprietary information from individuals outside the company or allow them to obtain access to Collate proprietary information. You should also check with the Legal team if developing a product feature that uses content not belonging to Collate.
Collate gives us the tools and equipment that we need to do our jobs effectively, but counts on us to be responsible and not wasteful. Uncertain whether personal use of company assets is okay? Ask your manager.
Collate’s network, software, and computing hardware are critical aspects of our company’s physical property and intellectual property. Follow all security policies diligently. If you have any reason to believe that our network security has been violated – for example, you lose your laptop or think that your network password may have been compromised – promptly report the incident to your manager.
Bad actors may steal company assets. Always secure your laptop, important equipment, and your personal belongings, even while on company premises. Promptly report any suspicious activity to your manager.
Ensure financial integrity and responsibility
Financial integrity and fiscal responsibility are core aspects of corporate professionalism. Each
person at Collate has a role in making sure that money is appropriately spent, our financial records are complete and accurate, and internal controls are honored. This is applicable every time that we hire a new vendor, expense something to Collate, or sign a new business contract.
It’s important that we also keep records for an appropriate length of time. Collate’s Data Retention Policy suggests minimum record retention periods for certain types of records. These guidelines help keep in mind applicable legal requirements, accounting rules, and other external requirements. Contractual obligations may sometimes specify longer retention periods for certain types of records. In addition, if you are asked by the Legal team to retain records relevant to a litigation, audit, or investigation, do so until Legal tells you that retention is no longer necessary. If you have any questions regarding the correct length of time to retain a record, contact the Compliance or Legal teams.
Obey the law
Collate takes its responsibilities to comply with laws very seriously. Every employee is expected to comply with applicable legal requirements and restrictions. You should understand the laws and regulations that apply to your work. Contact the Compliance or Legal teams if you have any questions.
The Compliance team will verify compliance with this Code through various methods (e.g. periodic manager reviews, tool reports, internal and external audits, and employee feedback). Exceptions
Any exception to this Code must be approved by the Compliance team in writing. Non-Compliance
Any employee who violates this Code may be subject to disciplinary action, up to and including
termination of employment in addition to any civil and criminal liability. Your Annual Acknowledgment of the Code of Conduct
Once each year, as a condition of your employment, you’re required to acknowledge that you have received the Code of Conduct and understand its rules. New employees will sign an acknowledgment when they start with the company. Basically, your annual acknowledgment confirms that:
- You’ve reviewed the Code of Conduct and you are required to comply with the Code of Conduct; you will comply with the compliance policies and procedures, as well as policies and procedures related to your job responsibilities;
- You will report any questions or concerns about suspected or actual violations of the Code to your supervisor, anyone in management, or Collate’s Compliance Officer,
- To the best of your knowledge, you haven’t acted contrary to the Code of Conduct
- You have reported any potential conflicts of interest to the Compliance Department.
5. Data Deletion Policy
SOC 2 Criteria: CC6.5
Keywords: Data Retention, Grace Period
This policy outlines the requirements and controls/procedures Collate has implemented to manage the deletion of customer data.
Customer data is retained for as long as the account is in active status. Data enters an “expired” state when the account is voluntarily closed. Expired account data will be retained for seven days. After this period, the account and related data will be removed. Customers that wish to voluntarily close their account should download their data manually or via the API prior to closing their account.
If a customer account is involuntarily suspended, then there is a seven days grace period during which the account will be inaccessible but can be reopened if the customer meets their payment obligations and resolves any terms of service violations.
If a customer wishes to manually backup their data in a suspended account, then they must ensure that their account is brought back to good standing so that the user interface will be available for their use. After seven days, the suspended account will be closed and the data will enter the “expired” state. It will be permanently removed seven days thereafter (except when required by law to retain).
6. Data Protection Policy
SOC 2 Criteria: CC6.1, CC6.7
ISO 27001 Annex A: A.8.2.3, A.8.3.1, A.8.3.2, A.8.3.3, A.12.1.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.13.2.1, A.13.2.2, A.13.2.3, A.18.1.3
Keywords: Data encryption at rest, Data encryption in transit, Data separation, Cloud monitoring
Collate takes the confidentiality and integrity of its customer data very seriously and strives to assure data is protected from unauthorized access and is available when needed.
This policy outlines many of the procedures and technical controls in support of data protection.
Production systems that create, receive, store, or transmit Collate customer data (hereafter "Production Systems") must follow the requirements and guidelines described in this policy.
Roles and Responsibilities
The CTO and Security Team are responsible for updating, reviewing, maintaining, and enforcing this policy and all statements within this policy.
Collate policy requires that:
- Data must be handled and protected according to its classification requirements and following approved encryption standards, if applicable.
- Whenever possible, store data of the same classification in a given data repository and avoid mixing sensitive and non-sensitive data in the same repository. Security controls, including authentication, authorization, data encryption, and auditing, should be applied according to the highest classification of data in a given repository.
- Employees shall not have direct administrative access to production data during normal business operations. Exceptions include emergency operations such as forensic analysis and manual disaster recovery.
- All Production Systems must disable services that are not required to achieve the business purpose or function of the system.
- Any access to Production Systems must be logged.
- All Production Systems must have security monitoring enabled, including activity and file integrity monitoring, vulnerability scanning, and/or malware detection, as applicable.
Data Protection Implementation and Processes Customer Data Protection
Collate hosts on AWS in Northern California, North Carolina, Paris, Frankfurt, Mumbai, Sydney regions. Customers have an option to choose which region they want to Collate SaaS instance. Data is replicated across multiple zones within the region they selected for redundancy and disaster recovery.
All Collate employees adhere to the following processes to reduce the risk of compromising Production Data:
- Implement and/or review controls designed to protect Production Data from improper alteration or destruction.
- Ensure that confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
- Ensure Collate Customer Production Data is segmented and only accessible to customers authorized to access data.
- All Production Data at rest is stored on encrypted volumes using encryption keys managed by Collate.
- Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
Collate employee access to production is guarded by an approval process and by default is disabled. When access is approved, temporary access is granted that allows access to production. Production access is reviewed by the security team on a case-by-case basis.
Customer data is physically separated at the database/datastore level. The separation is enforced by providing a completely isolated Collate's SaaS instance per customer. All data stored in database/datastore is physically separated and isolated per customer.
Collate uses AWS cloud watch to monitor the entire cloud service operation. If a system failure and alarm is triggered, key personnel are notified by text, chat, and/or email message in order to take appropriate corrective action.
Confidentiality/Non-Disclosure Agreement (NDA)
Collate uses confidentiality or non-disclosure agreements to protect confidential information using legally enforceable terms. NDAs are applicable to both internal and external parties. NDAs will have the following elements:
- Definition of the information to be protected
- Duration of the agreement
- Required actions upon termination of agreement
- Responsibilities and actions to avoid unauthorized disclosure
- Ownership of information, trade secrets, and intellectual property
- Permitted use of the confidential information and rights to use information
- Audit and monitor activities that involve confidential information
- Process of notification and reporting of unauthorized disclosure or information leakage
- Information return or destruction terms when an agreement is terminated
- Actions in case of breach of agreement
- Periodic review
Data At Rest Encryption
All databases, data stores, and file systems are encrypted according to Collate’s Encryption Policy.
Stored data must be properly categorized and a retention schedule applied accordingly in conjunction with Collate's Asset Management Policy, Data Classification Policy, and Data Deletion Policy. Considerations for retention timeframe include:
- Statutory, regulatory, or contractual requirements
- Type of data (e.g., accounting records, database records, audit logs)
- Type of storage media (e.g., paper, hard drive, server)
Storage and Disposal
Stored data must be properly stored and handled while at rest. Considerations for storage and disposal of data at rest in conjunction with Collate's Asset Management Policy, Data Classification Policy, and Data Deletion Policy include:
- Authorization to access or manage stored data
- Proper identification of records and their retention period
- Technology change and the ability to access data throughout the retention period
- Acceptable timeframe and format to retrieve data
- Appropriate methods of disposal
Data In Transit
Data will only be transferred where strictly necessary for effective business processes. Transfer Factors
Before choosing the method of data transfer, the following must be considered:
- Nature, sensitivity, confidentiality, and value of the information
- Size of data being transferred
- Impact of loss during transit
To ensure the safety of data in transit:
- All external data transmission must be encrypted end-to-end using encryption keys managed by Collate. This includes, but is not limited to, cloud infrastructure and third- party vendors and applications.
- All internet and intranet connections are encrypted and authenticated using a strong protocol, a strong key exchange, and a strong cipher.
End-user Messaging Channels
Restricted and sensitive data is not allowed to be sent over electronic end-user messaging channels such as email or chat unless end-to-end encryption is enabled.
- Messages must be protected from unauthorized access, modification, or denial of service commensurate with the classification scheme adopted by the organization.
- Messages must be reviewed prior to sending to ensure correct addressing and transportation of the message.
- The reliability and availability of the messaging channel must be verified.
- All applicable legal requirements will be adhered to.
- The use of external public services such as instant messaging, social networking, or file- sharing will require prior approval and authorization.
- Publicly accessible networks will be controlled by stronger authentication.
All Collate systems that handle confidential information accept network connections, or make access control (authentication and authorization) decisions will record and retain audit-logging information sufficient to answer: What activity was performed? Who performed it? Where, when, and how (with what tools) was it performed? And, what was the status, outcome, or result of the activity?
The logs will be created whenever the system is asked to perform any of the following activities:
- Create, read, update, or delete confidential information, including confidential authentication information such as passwords;
- Create, update, or delete information not covered in the above item;
- Initiate a network connection;
- Accept a network connection;
- User authentication and authorization for activities covered above such as user login and logout;
- Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes;
- System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes;
- Application process startup, shutdown, or restart;
- Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault; and
- Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.
Each log will identify or contain at least the following elements, directly or indirectly (unambiguously inferred):
- Type of action – examples include authorize, create, read, update, delete, and accept network connection.
- Subsystem performing the action – examples include process or transaction name, process or transaction identifier.
- Identifiers (as many as available) for the subject requesting the action – examples include a user name, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
- Identifiers (as many as available) for the object the action was performed on – examples include file names accessed, unique identifiers of records accessed in a database, query parameters used to determine records accessed in a database, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
- Before and after values when the action involves updating a data element, if feasible.
- Date and time the action was performed, including relevant time-zone information if not in Coordinated Universal Time.
- Whether the action was allowed or denied by access-control mechanisms.
- Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.
Formatting, Storage, Clock Synchronization
- The system will support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. Note that the construction of an actual enterprise-level log management mechanism is outside the scope of this document.
- The system will also ensure clock synchronization for the accuracy of audit logs. A clock linked to a radio time broadcast from a national atomic clock can be used as the master clock for logging systems. A network time protocol will be used to keep all of the servers in synchronization with the master clock.
Administrators and Operator Logs
To safeguard and prevent manipulation of logs by privileged users the following will be implemented where appropriate and possible:
- System administrators are not permitted to erase or de-activate logs of their own activities.
- Real-time copying of logs to a system outside the control of a system administrator or operator.
- Monitoring system and network administration activities by using an intrusion detection system managed outside of the control of the system and network administrators.
- Frequent review of logs to maintain accountability of privileged users.
7. Disaster Recovery Plan
SOC 2 Criteria: CC5.3, CC7.5
ISO 27001 Annex A: A.5.1.1, A.11.1.4, A.12.3.1, A.17.1.1, A.17.1.2, A.17.1.3
Keywords: Tabletop testing, Disaster Recovery Simulation
This policy establishes procedures to recover Collate following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the Collate Security Officer and Privacy Officer.
The following objectives have been established for this plan:
Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:
- Notification/Activation phase to detect and assess damage and to activate the plan.
- Recovery phase to restore temporary operations and recover damage done to the original system.
- Reconstitution phase to restore system processing capabilities to normal operations.
Identify the activities, resources, and procedures needed to carry out Collate processing requirements during prolonged interruptions to normal operations.
Identify and define the impact of interruptions to Collate systems.
Assign responsibilities to designated personnel and provide guidance for recovering Collate systems during prolonged periods of interruption to normal operations.
Ensure coordination with other Collate staff who will participate in the Disaster Recovery Planning strategies.
Ensure coordination with external points of contact and vendors who will participate in the Disaster Recovery Planning strategies.
Examples of the types of disasters that would initiate this plan are natural disaster, political disturbances, human-made disaster, external human threats, internal malicious activities.
Collate defines two categories of systems from a disaster recovery perspective:
1. Critical Systems
These systems host application servers and database servers or are required for the functioning of systems that host application servers and database servers. These systems, if unavailable, affect the integrity of data and must be restored, or have a process begun to restore them, immediately upon becoming unavailable.
2. Non-critical Systems.
These are all systems not considered critical by the definition above. These systems, while they may affect the performance and overall security of critical systems, do not prevent Critical systems from functioning and being accessed appropriately. These systems are restored at a lower priority than critical systems.
Threat and Risk Assessment and Management
There are many potential disruptive threats that can occur at any time and affect the normal business process. We have considered a wide range of potential threats and the results of our deliberations are included in this section. Each potential environmental disaster or emergency situation has been examined. The focus here is on the level of business disruption which could arise from each type of disaster.
The Collate IT Risk Assessment documents a full detailed assessment of threats.
Testing and Maintenance
The Security Officer shall establish criteria for validation/testing of a Disaster Recovery Plan, an annual test schedule, and ensure implementation of the test. This process will also serve as training for personnel involved in the plan's execution. At a minimum, the Disaster Recovery Plan shall be tested every 3 months. The types of validation/testing exercises include tabletop and technical testing.
The primary objective of the tabletop test is to ensure designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures as outlined in the Disaster Recovery Plan, in a timely manner. The exercises include, but are not limited to:
- Testing to validate the ability to respond to a crisis in a coordinated, timely, and effective manner, by simulating the occurrence of a specific crisis.
The primary objective of the technical test is to ensure the communication processes and data storage and recovery processes can function at an alternate site to perform the functions and capabilities of the system within the designated requirements. Technical testing shall include, but is not limited to:
- The process from the backup system at the alternate site
- Restore system using backups
- Switch compute and storage resources to an alternate processing site.
Disaster Recovery Procedures
Notification and Activation Phase
This phase addresses the initial actions taken to detect and assess the damage inflicted by a disruption to Collate. Based on the assessment of the Event, sometimes according to the Collate Incident Response Policy, the Disaster Recovery Plan may be activated by the Security Officer and/or CTO.
The notification sequence is listed below:
- The first responder is to notify the CTO. All known information must be relayed to the CTO.
- The CTO is to contact the rest of the team and inform them of the event. The CTO is to begin assessment procedures.
- The CTO is to notify team members and direct them to complete the assessment procedures outlined below to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the CTO is to follow the steps below.
Damage Assessment Procedures:
- The CTO is to logically assess the damage, gain insight into whether the infrastructure is salvageable, and begin to formulate a plan for recovery.
Alternate Assessment Procedures:
- Upon notification, the CTO is to follow the procedures for damage assessment with combined DevOps and Web Services Teams.
- The Collate Disaster Recovery Plan is to be activated if one or more of the following criteria are met:
- Collate systems will be unavailable for more than 48 hours.
- The hosting facility is damaged and will be unavailable for more than 24 hours.
- Other criteria, as appropriate and as defined by Collate.
- If the plan is to be activated, the CTO is to notify and inform team members of the details of the event and if relocation is required.
- Upon notification from the CTO, group leaders and managers are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary.
- The CTO is to notify the hosting facility partners that a contingency event has been declared and to ship the necessary materials (as determined by damage assessment) to the alternate site.
- The CTO is to notify the remaining personnel and executive leadership of the general status of the incident.
- Notification can be delivered via message, email, or phone.
This section provides procedures for recovering the application at an alternate site, whereas other efforts are directed to repair damage to the original system and capabilities.
The following procedures are for recovering the Collate infrastructure at the alternate site. Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.
Recovery Goal: The goal is to rebuild Collate infrastructure to a production state. The tasks outlined below are not sequential and some can be run in parallel.
- Contact Partners and Customers affected.
- Assess damage to the environment.
- Begin replication of new environment using automated and tested scripts. At this point, it is determined whether to recover in AWS, GCP, Azure, or another cloud environment.
- Test new environment using pre-written tests.
- Test logging, security, and alerting functionality.
- Assure systems are appropriately patched and up to date.
- Deploy environment to production.
- Update DNS to a new environment.
This section discusses activities necessary for restoring Collate operations at the original or new site. The goal is to restore full operations within 24 hours of a disaster or outage. When the hosted data center at the original or new site has been restored, Collate operations at the alternate site may be transitioned back. The goal is to provide a seamless transition of operations from the alternate site to the computer center.
Original or New Site Restoration
Begin replication of new environment using automated and tested scripts - DevOps
- Test new environment using pre-written tests. - Web Services
- Test logging, security, and alerting functionality. - Dev Ops
- Deploy environment to production - Web Services
- Assure systems are appropriately patched and up to date. - Dev Ops
- Update DNS to a new environment. - Dev Ops
If the Collate environment is moved back to the original site from the alternative site, all hardware used at the alternate site should be handled and disposed of according to Collate policy.
8. Information Security Policy
SOC 2 Criteria: CC1.2, CC1.3, CC2.1, CC5.1, CC5.2, CC5.3
ISO 27001 Requirements: 6.2
ISO 27001 Annex A: A.5.1.1, A.6.1.5, A.6.2.1, A.6.2.2, A.7.1.2, A.7.2.2, A.7.2.3, A.7.3.1, A.11.2.8, A.11.2.9, A.12.6.1, A.18.1.2
Keywords: Corrective action, Security training, Clean desk
Collate’s Information Security Policy has been developed to: establish a general approach to information security and the minimization of information misuse, compromise or loss; document security processes and measures; uphold ethical standards and meet the company’s regulatory, legal, contractual, and other obligations; control business risk; and ensure that the appropriate company image and reputation is presented.
This policy applies to:
- Information in any form, regardless of the media on which it is stored, as well as, any facility, system, or network used to store, process, and/or transfer information.
- All Collate employees, temporary staff, partners, contractors, vendors, suppliers, and any other person (collectively also referred to as “Staff” or “Personnel”) or entity that accesses the company’s networks or any other public or private network through company’s networks or systems.
- All activity while using or accessing the company’s information or information processing, storage, or transmission equipment, while on the company premises (owned, rented, leased, or borrowed) or remotely.
- Information resources that have been entrusted to the company by any entity external to the company (i.e. Customers, Staff, and others).
- Documents, messages, and other communications created on or communicated via the company systems are considered the company’s business records and, as such, are
subject to review by third parties in relation to audits, litigation, process improvement, and compliance.
This policy is the overarching policy over the rest of the security policies, which make up the Collate's information security program (ISP). The series of security policies includes:
- Acceptable Use Policy
- Asset Management Policy
- Backup Policy
- Business Continuity/Disaster Recovery Plans
- Code of Conduct
- Data Classification, Deletion, and Protection Policies
- Encryption and Password Policies
- Incident Response Plan
- Physical Security Policy
- Responsible Disclosure Policy
- Risk Assessment Policy
- Software Development Life Cycle Policy
- System Access Management Policy
- Vendor Management Policy
- Vulnerability Management Policy
Information Security Objectives
It is the policy of Collate that information, as defined hereinafter, in all its forms--written, spoken, recorded electronically or printed--will be protected from accidental or intentional unauthorized modification, destruction or disclosure throughout its life-cycle. This protection includes an appropriate level of security over the equipment and software used to process, store, and transmit that information. Ultimately, the information security goal of Collate is to maintain:
- Confidentiality: data and information are protected from unauthorized access
- Integrity: Data is intact, complete and accurate
- Availability: IT systems are available when needed
Collate’s information security objectives, consistent with the company’s information security program are:
- To protect information from all internal, external, deliberate, or accidental threats;
- To enable secure information sharing;
- To encourage consistent and professional use of information;
- To ensure clarity about roles and responsibilities associated with protecting information;
- To ensure business continuity and minimize business damage; and,
- To protect the company from legal liability and the inappropriate use of information.
Roles and Responsibilities
The Security Officer/CISO is responsible for:
- The design, development, maintenance, dissemination, and enforcement of the items contained in this policy and other ISP policies.
- [For ISO 27001] Ensuring that the information security management system conforms to the requirements of ISO/IEC 27001:2013.
- Reporting on the performance of the information security program to top management.
The objectives and measures outlined by the ISP policies shall be maintained and enforced by the roles and responsibilities specified in each policy and the company Skills Matrix.
At a minimum on an annual basis, a security and/or compliance committee composed of senior management and key personnel must discuss, evaluate and document the company’s ISP, ensuring strategic goals and objectives are continually being developed.
At a minimum on an annual basis, all ISP policies must be reviewed, modified, and/or edited to meet necessary security standards. All policies must be signed and approved by authorized personnel.
Policies and/or procedures must be accessible to employees for review at all times via the compliance automation SaaS, Drata. Policies pertaining to positions must be reviewed and signed upon hire and on an annual basis by all employees.
Requests for any exceptions to any policies included within the ISP must be approved by Collate’s Executive Management. after proper review. Any approved exceptions will be reviewed annually.
Management shall ensure that employees, contractors, and third-party users:
- Are properly briefed on their information security roles and responsibilities prior to being granted access to covered information or information systems;
- Are provided with guidelines that state security expectations of their role within the organization;
- Are motivated and comply with the security policies of the organization;
- Achieve a level of awareness on security-relevant to their roles and responsibilities within the organization;
- Conform to the terms and conditions of employment, which include the organization’s information security policy and appropriate methods of working.
All new hires are required to complete information security awareness training as part of their new employee onboarding process and annually thereafter. New hire onboarding will be completed within
Additional specialized training will be required for individuals responsible for maintaining system security. Specialized topics would include spam, phishing, OWASP Top Ten list, and SANS Top 25 list. In addition, consistent with assigned roles and responsibilities, incident response and contingency training for personnel will be done:
- within 90 days of assuming an incident response role or responsibility;
- as required by information system or policy changes; and,
The organization will properly document that the training has been provided to all employees.
All employees are required to acknowledge in writing their understanding of the Information Security Program which includes a Code of Conduct upon hire and annually thereafter.
Clean Desk/Work Area Policy
Authorized users will ensure that all sensitive/confidential materials, hardcopy or electronic, are removed from their workspace and locked away when the items are not in use or an employee leaves his/her workstation. This will also increase awareness about protecting sensitive information. As such:
- Employees are required to ensure that all sensitive/confidential information, hardcopy or electronic form, is secure in their work area at the end of the day and when they are expected to be gone for an extended period.
- Computer workstations must be locked when the workspace is not in use and must be shut down completely at the end of the day.
- Sensitive information must be removed from the desk and securely stored when the desk is unattended, and at the end of the day.
- Laptops and other portable computing devices must be properly stored/secured.
- File cabinets containing Restricted or Sensitive information must be kept closed and locked when not in use or when not attended to.
- Keys used for access to Restricted or Sensitive information must not be left at an unattended desk.
- Passwords may not be left on sticky notes posted on or under a computer, nor may they be left written down in an accessible location.
- Printouts containing Restricted or Sensitive information should be immediately removed from the printer.
- Upon disposal, Restricted and/or Sensitive documents should be shredded in the official shredder bins or placed in the locked confidential disposal bins.
- Whiteboards containing Restricted and/or Sensitive information should be erased.
- Treat mass storage devices such as external hard drives or USB drives as sensitive and always secure and encrypt them.
- All printers and fax machines should be cleared of papers as soon as they are printed; this helps ensure that sensitive documents are not left in printer trays for the wrong person to pick up.
Intranet Access and Use
Use of Collate computers, networks, and Internet access is a privilege granted by management and may be revoked at any time for inappropriate conduct carried out on such systems, including, but not limited to:
- Sending chain letters or participating in any way in the creation or transmission of unsolicited "spam" that is unrelated to legitimate Company purposes;
- Engaging in private or personal business activities, including excessive use of instant messaging and chat rooms;
- Accessing networks, servers, drives, folders, or files to which the employee has not been granted access or authorization from someone with the right to make such a grant;
- Making unauthorized copies of Company files or other Company data;
- Destroying, deleting, erasing, or concealing Company files or other Company data, or otherwise making such files or data unavailable or inaccessible to the Company or to
other authorized users of Company systems;
- Misrepresenting oneself or the Company;
- Violating the laws and regulations of federal, state, city, province, or local jurisdictions in any way;
- Engaging in unlawful or malicious activities;
- Deliberately propagating any virus, worm, Trojan horse, trap-door program code, or other code or file designed to disrupt, disable, impair, or otherwise harm either the Company's networks or systems or those of any other individual or entity;
- Using abusive, profane, threatening, racist, sexist, or otherwise objectionable language in either public or private messages;
- Sending, receiving, or accessing pornographic materials;
- Causing congestion, disruption, disablement, alteration, or impairment of Company networks or systems;
- Using recreational games; and/or
- Defeating or attempting to defeat security restrictions on company systems and applications.
Such access will be discontinued upon the termination of employment, contract completion, end of service of non-employee, or disciplinary action arising from the violation of this policy. In the case of a change in job function and/or transfer, the original access code will be discontinued, and only reissued if necessary and a new request for access is approved.
All user IDs that have been inactive for thirty (30) days will be revoked. The privileges granted to users must be reevaluated by management annually. In response to feedback from management, systems administrators must promptly revoke all privileges no longer needed by users.
- Secure remote access must be strictly controlled with encryption (i.e., Virtual Private Networks (VPNs)) and strong pass-phrases. Refer to the Encryption Policy and the Password Policy for further information.
- Authorized Users must protect their login and password, without exception.
- While using a Collate-owned computer to remotely connect to the company's network, authorized users must ensure the remote host is not connected to any other network at the same time, with the exception of personal networks that are under their complete control or under the complete control of an authorized user or third party.
- The most up-to-date antivirus software must be used on all computers. Third-party connections must comply with requirements as stated in the Vendor Management Agreement.
- Equipment used to connect to Collate's networks must meet the requirements for remote access and device use as stated in the Acceptable Use Policy, Asset Management Policy, and System Access Control Policy.
Remote Access Tools:
All remote access tools used to communicate between Collate assets and other systems must comply with the following policy requirements:
- Multi-factor authentication (such as authentication tokens and smart cards that require an additional PIN or password) is required for all remote access tools
- The authentication database source must be an SSO provider such as Google, and the authentication protocol must involve a challenge-response protocol that is not susceptible to replay attacks. The remote access tool must mutually authenticate both ends of the session.
- Remote access tools must support the Collate application layer proxy rather than direct connections through the perimeter firewall(s).
- Remote access tools must support strong, end-to-end encryption of the remote access communication channels as specified in the Encryption Policy.
- All antivirus, data loss prevention, and other security systems must not be disabled, interfered with, or circumvented in any way.
Mobile Endpoint and Storage Devices
Protecting endpoint devices issued by Collate or storing company data is the responsibility of every employee. This pertains to all devices that connect to the company network, regardless of ownership. Mobile endpoint and storage devices are defined to include: desktop systems (in telework environment), laptops, PDAs, mobile phones, plug-ins, Universal Serial Bus (USB) port devices, Compact Discs (CDs), Digital Versatile Discs (DVDs), flash drives, modems, handheld wireless devices, wireless networking cards, and any other existing or future mobile computing or storage device, either personally owned or Collate owned. An inventory of company-owned assets will be properly maintained.
For endpoint devices:
- Company-issued mobile devices will have antivirus and endpoint security pre-installed.
- Users must run an online malware scanner at least once a month.
- If browser add-ons are approved and installed, a browser testing tool shall be run to ensure the security of the add-on.
- Mobile endpoint devices must further meet the requirements for use as stated in the Acceptable Use Policy and Asset Management Policy.
For storage devices:
- A risk analysis will be conducted prior to the use or connection to the company network unless previously approved.
- Detection of incidents must immediately be reported to the [RESPONSIBLE PARTY, e.g., information security team].
- Stolen mobile devices must immediately be reported to the [RESPONSIBLE PARTY, e.g., information security team].
Intellectual Property Rights
Collate takes handling and safeguarding of intellectual property very seriously. Intellectual property rights include software or document copyright, design rights, trademarks, patents, and source code licenses.
To ensure this the following procedures will be maintained:
- Software will only be acquired through known and reputable sources, to ensure that copyright is not violated.
- An asset inventory will identify all assets with requirements to protect intellectual property rights.
- Proof and evidence of ownership of licenses, master disks, manuals, etc. will be maintained.
- Review of the asset inventory will also make sure that only software and licensed products are installed.
- Will ensure compliance with terms and conditions for software and information obtained from public networks
Information Security Requirements Analysis & Specifications
Collate will identify its information security requirements by utilizing different methods, ensure the results of the identification are documented and reviewed by all stakeholders and will integrate the requirements and associated processes in the early stages of projects.
- Policies and regulations
- Threat modeling
- Incident reviews
- Use of vulnerability thresholds
- Level of confidence required towards the claimed identity of users, in order to derive user authentication requirements.
- Access provisioning and authorization processes, for business and privileged or technical users.
- Informing users and operators of their duties and responsibilities.
- Protection needs of assets, especially in terms of availability, confidentiality, and integrity.
- Business processes (e.g., transaction logging and monitoring, non-repudiation requirements).
- Other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems).
Employment Terms and Conditions
The following terms and conditions of employment at Collate are the contractual obligations for employees or contractors for the safeguarding of information. They include, but are not limited to:
- Signing a confidentiality or non-disclosure agreement (NDA) prior to access to confidential information and processing facilities.
- Legal responsibilities and rights, particularly concerning intellectual property.
- Responsibilities for the classification of information and management of organizational assets associated with information, information processing facilities, and information services handled by an employee or contractor.
- Responsibilities for information handling received from third parties.
- Reviewing and agreeing with the security policies of the company.
- Duration of responsibilities beyond the end of employment.
- Actions to be taken for non-compliance with the terms and conditions, and the company’s security policies.
Collate’s discipline policy and procedures are designed to provide a structured corrective action process to improve and prevent a recurrence of undesirable employee behavior and performance issues. It has been designed to be consistent with Collate cultural values, Human Resources (HR) best practices, and employment laws.
Collate reserves the right to combine or skip steps depending on the facts of each situation and the nature of the offense. The level of disciplinary intervention may also vary. Some of the factors that will be considered are whether the offense is repeated despite coaching, counseling, or training, the employee’s work record and the impact the conduct and performance issues have on the organization.
Step 1: Verbal Warning and Counseling
This initial step creates an opportunity for the immediate supervisor to schedule a meeting with an employee to bring attention to an existing performance, conduct, or attendance issue. The supervisor should discuss with the employee the nature of the problem or the violation of company policies and procedures. The supervisor is expected to clearly describe expectations and the steps the employee must take to improve performance or resolve the problem.
Step 2: Formal Written Warning
If the employee does not promptly correct any performance, conduct, or attendance issues that were identified in Step 1, a written warning will become formal documentation of the performance, conduct, or attendance issues and consequences. The employee will sign a copy of the document to acknowledge receipt and understanding of the formal warning. During Step 2, the immediate supervisor and HR representative will meet with the employee to review any additional incidents or information about the performance, conduct, or attendance issues as well as any prior relevant corrective action plans. Management will outline the consequences for the employee of his or her continued failure to meet performance or conduct expectations.
A formal performance improvement plan (PIP) requiring the employee’s immediate and sustained corrective action will be issued after a Step 2 meeting. A warning outlining that the employee may be subject to additional discipline up to and including termination if immediate and sustained corrective action is not taken may also be included in the written warning.
Step 3: Suspension and Final Written Warning
There may be performance, conduct, or safety incidents so problematic and harmful that the most effective action may be the temporary removal of the employee from the workplace. When immediate action is necessary to ensure the safety of the employee or others, the immediate supervisor may suspend the employee pending the results of an investigation. Suspensions that are recommended as part of the normal progression of this progressive discipline policy and procedure are subject to approval from a next-level manager and HR.
Step 4: Recommendation for Termination of Employment
The last step in the progressive discipline procedure is a recommendation to terminate employment. Generally, Collate will try to exercise the progressive nature of this policy by first providing warnings, a final written warning, or suspension from the workplace before proceeding to a recommendation to terminate employment. However, Collate reserves the right to combine and skip steps depending on the circumstances of each situation and the nature of the offense. Furthermore, employees may be terminated without prior notice or disciplinary action.
Management’s recommendation to terminate employment must be approved by HR and the supervisor’s immediate manager. Final approval may be required from the CEO.
Performance and Conduct Issues Not Subject to Progressive Discipline
Behavior that is illegal is not subject to progressive discipline, and such behavior may be reported to local law enforcement authorities. Theft, substance abuse, intoxication, fighting and other acts of violence at work are grounds for immediate termination.
Collate Management, under the explicit authority granted by the company CEO, retains the authority and responsibility to monitor and enforce compliance with this Policy and other policies, standards, procedures, and guidelines. Monitoring activities may be conducted on an ongoing basis or on a random basis whenever deemed necessary by Management and may require investigating the use of the Company’s information resources. The company reserves the right to review any and all communications and activities without notice.
Collate will take appropriate precautions to ensure that monitoring activities are limited to the extent necessary to determine whether the communications or activities are in violation of Company policies, standards, procedures, and guidelines or in accordance with normal business processing performance or quality activities.
Violation of the controls established in this Policy is prohibited and will be appropriately addressed. Disciplinary actions for violations may include verbal and/or written warnings, suspension, termination, and/or other legal remedies and will be consistent with our published HR standards and practices.
9. Password Policy
SOC 2 Criteria: CC6.1
ISO 27001 Annex A: A.9.2.4, A.9.3.1
Keywords: Password requirements, Password Manager, Complex passwords, 2FA, MFA
This policy describes the procedure to select and securely manage passwords at Collate.
This policy applies to all Collate employees, contractors, and any other personnel who have an account on any system that resides at any company facility or has access to the company network.
Roles and Responsibilities
If a password is suspected of being compromised, the password in question should be rotated and the Security Officer should be notified immediately.
- Complex passwords are required where possible. Complex passwords have at least 10 characters, 1+ uppercase letter(s), 1+ lowercase letter(s), 1+ non-alphanumeric character(s)
- Passwords must have at least 10 characters
- Do not reuse previously used passwords or their variants
- Do not use commonly used passwords
- MFA must be enabled for any and all systems that provide the option for Multi-Factor Authentication (MFA)
- All passwords are treated as confidential information and should not be shared with anyone. If you receive a request to share a password, deny the request and contact the system owner for assistance in provisioning an individual user account.
- If you are required to maintain your own secret authentication information, you will be provided initially with a unique, individual, and secure temporary secret authentication information in a secure manner, which you must acknowledge its receipt and change on first use.
- Do not write down passwords, store them in emails, electronic notes, or mobile devices, or share them over the phone. If you must store passwords electronically, do so with a password manager that has been approved by Collate:
- Collate’s approved Password Manager: 1password, LastPass
- If you absolutely must share a password, do so through the approved password manager or grant access to an application through a single-sign-on (SSO) provider.
- If you suspect a password has been compromised, rotate the password immediately and notify the Company’s Security Officer.
- Passwords stored in systems must be stored with a unique salt and as a one-way hash using an approved password hashing algorithm (pbkdf2, bcrypt, scrypt) and an HMAC- SHA256
- An employee or contractor found to have violated this policy may be subject to disciplinary action.
10. Physical Security Policy
SOC 2 Criteria: CC6.4
ISO 27001 Annex A: A.11.1, A.11.2.1, A.11.2.2, A.11.2.3, A.11.2.5, 11.2.6
Keywords: Facilities, Office visitors, Access Requirements, Asset Security
The Physical Security Policy establishes requirements to ensure that Collate’s information assets are protected by physical controls that prevent tampering, damage, theft, or unauthorized physical access. This policy defines the following controls and acceptable practices:
- Definition of physical security perimeters and required controls
- Personnel and visitor access controls
- Protection of equipment stored off-site
This policy applies to all Collate physical facilities and users of information systems within Collate, which typically include employees and contractors, as well as any external parties that have physical access to the company’s information systems. This policy must be made readily available to all users.
It is the goal of Collate to safeguard information both virtually and physically, as well
to provide a safe and secure environment for all employees. As such, access to the Collate facilities is limited to authorized individuals only. All workforce members are responsible for reporting an incident of unauthorized visitor and/or unauthorized access to Collate's facility.
Roles and Responsibilities
- Physical access to Collate facilities is restricted.
- All employees are required to wear employee badges at secure facilities if and when applicable (such as server rooms, data centers, and labs).
- All employees must follow physical security requirements and procedures documented by facility management.
- On-site visitors and vendors must be escorted by a Collate employee at all times while on the premises.
- All workforce members are responsible for reporting an incident of unauthorized visitor and/or unauthorized access to Collate's facility.
- A record is retained for each physical access, including visits, maintenance and repairs to Collate production environments, and secure facilities.
- Details must be captured for all maintenance and repairs performed to physical security equipment such as locks, walls, doors, surveillance cameras; and
- All records must be retained for a minimum of seven years.
- Building security, such as fire extinguishers and detectors, escape routes, and floor warden responsibilities, shall be maintained according to applicable laws and regulations.
- Physical access is restricted using badge readers and/or smart locks that track all access.
- Restricted areas and facilities are locked when unattended (where feasible).
- Only authorized workforce members receive access to restricted areas (as determined by the Security Officer).
- Access and keys are revoked upon termination of workforce members.
- Workforce members must report a lost and/or stolen key(s) or badge(s) to his/her manager, local Site Lead, or the Facility Manager.
- The Facility Manager or designee is responsible to revoke access to the lost/stolen badge(s) or access key(s) and re-provision access as needed.
- The Facility Manager or designee facilitates the changing of the lock(s) within 7 days of a physical key being reported lost/stolen.
- Visitor access requires additional controls.
- Visitors must sign a visitor’s log indicating the date and time in/out, organization represented (if applicable), the purpose of visit, and company point of contact.
- Visitor badges will be issued to visitors and must be displayed at all times when in secure areas. Badges must be returned before leaving the facility or by the specified time.
- Delivery and Loading areas.
- Access to delivery and loading areas from outside of the facility will be restricted to only identified and authorized personnel.
- Such areas will be designed to ensure that access to other parts of the facility is restricted.
- Incoming material must be appropriately inspected for any discrepancies, issues, or potential threats, and must be registered in accordance with Asset Management procedures.
- When possible, incoming and outgoing shipments will be physically segregated.
- Enforcement of Facility Access Policies
- Report violations of this policy to the restricted area's department team leader, supervisor, manager, or director, or the Privacy Officer.
- Workforce members in violation of this policy are subject to disciplinary action, up to and including termination.
- Visitors in violation of this policy are subject to loss of vendor privileges and/or termination of services from Collate.
- Workstation Security
- Workstations may only be accessed and utilized by authorized workforce members to complete assigned job/contract responsibilities.
- All workforce members are required to monitor workstations and report unauthorized users and/or unauthorized attempts to access systems/applications as per the System Access Control Policy.
- All workstations purchased by Collate are the property of Collate and are distributed to personnel by the company.
Building Standards per Location Standard
- A security perimeter must be defined and established to protect areas containing sensitive data and critical information processing facilities.
- The walls, ceilings, and floor of any secure area must be of the same strength.
- Windows and doors have locks, and all entry points are secured by access control mechanisms and have cameras for additional monitoring as needed.
- Spaces around the perimeter are monitored with CCTV or security patrols.
- CCTV recordings need to be kept for at least 3 months.
- Alarms are activated outside working hours.
- The most sensitive assets must be stored in the most secure areas. Using the “onion technique”, each perimeter “layer” should house progressively more sensitive assets.
- Keys to all secure or public areas housing IT equipment (including wireless access points, gateways, and more) must be protected in a centralized fashion.
- A controlled reception area must establish where:
- All visitors are required to report first.
- Security guards challenge unknown persons.
- Offsite backup locations are physically secure for backups and the security measures are reviewed at least annually.
- Menlo Park, CA Office:
- The building is unlocked Monday-Friday from 9 am-4 pm
- After hours the building is secured and requires an access card for entry
- The office is secured and requires an access card for entry for after-hours access
- All server rooms are secured 24/7 and require an access card for entry
Data Center Securit
Physical security of data centers is ensured by Collate’s cloud infrastructure service provider.
The following factors will be considered and implemented, as applicable per risk assessments, and in conjunction with the following policies: Information Security Policy, Asset Management Policy, Data Protection, and Data Classification:
All assets owned or managed by Collate will be housed in designated facilities with a level of protection equivalent to the sensitivity and criticality of the asset and the associated information. Additionally, the following factors will be considered:
- The potential danger from environmental threats, including weather, malicious attacks, and accidents.
- Appropriate risk mitigation must be implemented to reduce the potential for an incident to occur.
- Monitoring environmental conditions in appropriate areas.
- At a minimum, monitoring will be performed for fire/smoke in the general facility areas.
- Internal secure areas must be subject to additional monitoring for temperature, water, power continuity, humidity and cleanliness.
- Implementation of environmental controls in accordance with risk assessments.
- Controls such as heating, ventilation, air conditioning, drainage, fire suppression, emergency lighting, continuous power and humidity control must be implemented in facilities, as appropriate.
- If applicable, data centers must contain elements of each environmental control at sufficient levels.
Continuous power will be provided for mission-critical information assets through battery- operated uninterrupted power supply (UPS) protection.
- Backup generators will be used in cases of higher levels of protection.
Emergency Power Shutoff
In the case of an emergency, emergency power-off switches will be located near emergency exits in equipment rooms to facilitate rapid power down.
Alarm system configurations must be periodically reviewed and evaluated to detect malfunctions in the supporting utilities and reconfigured when necessary.
Off-Site Equipment and Security
Equipment may only be taken off-site for valid business reasons and with authorization from the Information Owner.
- The equipment includes network and telecommunication devices, servers, power and cooling equipment
- Individuals taking equipment offsite are responsible for the physical protection of the system and must ensure the system is secured at all times.
- Equipment will be recorded as being removed off-site and recorded when returned.
Power and telecommunications cabling must be protected adequately against risks such as interference, data capture or physical damage.
- Cables must be easily identifiable through markers or labels to ensure minimal handling errors.
11. Responsible Disclosure Policy
SOC 2 Criteria: CC2.2, CC5.3 ISO 27001 Annex A: A.7.2.1
To allow for the reporting and disclosure of vulnerabilities discovered by external entities, and anonymous reporting of information security policy violations by internal entities.
Collate’s Responsible Disclosure Policy covers applies to Collate’s core platform and its information security infrastructure, and to internal and external employees or third parties.
Collate is committed to ensuring the safety and security of our customers. and employees. We aim to foster an environment of trust, and an open partnership with the security community, and we recognize the importance of vulnerability disclosures and whistleblowers in continuing to ensure safety and security for all of our customers, employees and company. We have developed this policy to both reflect our corporate values and to uphold our legal responsibility to good-faith security researchers that are providing us with their expertise and whistleblowers who add an extra layer of security to our infrastructure.
Roles and Responsibilities
Collate will not engage in legal action against individuals who submit vulnerability reports through our Vulnerability Reporting inbox. We openly accept reports for the currently listed Collate products. We agree not to pursue legal action against individuals who:
- Engage in testing of systems/research without harming Collate or its customers.
- Engage in vulnerability testing within the scope of our vulnerability disclosure program.
- Test on products without affecting customers, or receive permission/consent from customers before engaging in vulnerability testing against their devices/software, etc.
- Adhere to the laws of their location and the location of Collate. For example, violating laws that would only result in a claim by Collate (and not a criminal claim) may be acceptable as Collate is authorizing the activity (reverse engineering or circumventing protective measures) to improve its system.
- Refrain from disclosing vulnerability details to the public before a mutually agreed- upon timeframe expires.
Vulnerability Report/Disclosure How to Submit a Vulnerability
To submit a vulnerability report to Collate’s Product Security Team, please utilize the following email email@example.com
Preference, Prioritization, and Acceptance Criteria
We will use the following criteria to prioritize and triage submissions. What we would like to see from you:
- Well-written reports in English will have a higher probability of resolution.
- Reports that include proof-of-concept code equip us to better triage.
- Reports that include only crash dumps or other automated tool output may receive lower priority.
- Reports that include products not on the initial scope list may receive lower priority.
- Please include how you found the bug, the impact, and any potential remediation.
- Please include any plans or intentions for public disclosure.
What you can expect from Collate:
- A timely response to your email (within 2 business days).
- After triage, we will send an expected timeline and commit to being as transparent as possible about the remediation timeline as well as on issues or challenges that may extend it.
- An open dialog to discuss issues.
- Notification when the vulnerability analysis has completed each stage of our review.
- Credit after the vulnerability has been validated and fixed.
If we are unable to resolve communication issues or other problems, Collate may bring in a neutral third party to assist in determining how best to handle the vulnerability.
How to Submit a Report
To anonymously report an information security program violation or a violation of related laws and regulations, please utilize
Preference, Prioritization, and Acceptance Criteria
We will use the following criteria to prioritize and review submissions. What we expect from you:
- A detailed report made in good faith or based on a reasonable belief.
- Good Faith means the truthful reporting of a company-related violation of information security policies, procedures, or regulations, as opposed to a report made with reckless disregard or willful ignorance of facts.
- Reasonable Belief refers to the subjective belief in the truth of the disclosure AND that any reasonable person in a similar situation would objectively believe based on the facts.
- Details of the violation (i.e., what, how, why).
- Details of the reported event, with facts (i.e., who, where, when).
- You are NOT responsible for investigating the alleged violation, or for determining fault or corrective measures.
What you can expect from Collate:
- Your report will be submitted to the
- Protection of your identity and confidentiality.
- CAVEAT: It may be necessary for your identity to be disclosed when a thorough investigation, compliance with the law, or due process of accused members is required.
- Protection against any form of retaliation and harassment, such as termination, compensation decreases, or poor work assignments and threats of physical harm.
- If you believe that you are being retaliated against, immediately contact
- Any retaliation or harassment against you will result in disciplinary action.
- CAVEAT: Your right for protection against retaliation does not include immunity for any personal wrongdoing alleged in the report and investigated
- If you believe that you are being retaliated against, immediately contact
- Due process for you and for the accused member(s).
- Corrective actions taken to resolve a verified violation and a review and enhancement of applicable policies and procedures, if necessary or appropriate.
- Continuous information security awareness training and understanding your rights as a whistleblower.
12. Software Development Life Cycle Policy
SOC 2 Criteria: CC8.1
ISO 27001 Annex A: A.6.1.2, A.6.1.5, A.12.1.1, A.12.1.2, A.12.1.4, A.12.5.1, A.14.2.1, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.14.2.6, A.14.2.7, A.14.2.8
Keywords: Change management, OWASP, Software lifecycle
This policy defines the high-level requirements for providing business program managers, business project managers, technical project managers, and other program and project stakeholders guidance to support the approval, planning, and life-cycle development of Collate software systems aligned with the Information Security Program.
Roles and Responsibilities
Collate must establish and maintain processes for ensuring that its computer applications or systems follow an SDLC process that is consistent and repeatable, and maintains information security at every stage.
Software Development Phases and Approach Standard
A Software Development Project consists of a defined set of phases: Determine System Need Phase
The Determine System Need phase is the period of time in which an information system need is identified and the decision is made whether to commit the necessary resources to address the need.
Define System Requirements Phase
The Define System Requirements phase is the period in which the User Requirements are broken down into more detailed requirements which can be used during designing and coding. Applicable security requirements and controls will be identified through an information security risk assessment.
Design System Component Phase
The Design System Components phase transforms requirements into specifications to guide the work of the Development phase. The decisions made in this phase address how the system will meet the functional, physical, interface, data, and security requirements. Design phase activities may be conducted in an iterative fashion, producing a system design that emphasizes the functional features of the system and technical detail.
Build System Component Phase
The Build phase transforms the detailed system design into complete coded software units and eventually, into an integrated product for release. Each software unit and subsequent integrated units are tested thoroughly, including tests for security vulnerabilities. System documents that support installation and operations are also developed in this phase.
Evaluate System Readiness Phase
The evaluation phase ensures that the system, as designed and built, satisfies the requirements of the user, as well as applicable security requirements. Whenever possible, independent testers measure the system's ability to perform the functions that are required by the customer and ensure an acceptable level of quality, performance, and security. Once the phase is complete, it will be evident whether or not the system is ready for operation or redevelopment.
System Deployment Phase
The system Deployment phase is the final phase of the development life cycle when the system is released initially to a pilot site, where any further security vulnerabilities can be identified, and then into the production environment. All necessary training for using the system is accomplished.
The sequence of the development phases depends on the software development approach taken. The project management approaches include but are not limited to:
- Waterfall Development
- Agile Development
- Iterative Development
- Staged Delivery Development
Based on the approach for, and the size of, the software development, some of the phases can be combined. In Iterative Development there may be multiple Cycles (iterations) of the above phases before the final software is released.
Secure System Engineering Principles
Information security implications will be addressed and reviewed regularly, and responsibilities for information security will be defined and allocated to the roles defined in the project management methods.
Engineering principles for a secure system will fall under the following categories:
- Business layer
- Data Layer
SDLC Security Control Guidelines
The SDLC process will adhere to the following information security controls:
- Adequate procedures should be established to provide separation of duties in the origination and approval of source documents. This shall include but not be limited to separation of duties between Personnel assigned to the development/test environment and those assigned to the production environment.
- Modification of code or an emergency release will follow the change control standard.
- Secure programming standards should be followed. Secure code training should be provided to Collate’s developers.
- A secure development environment will be created, based on:
- sensitivity of data to be processed, stored, and transmitted by the system;
- applicable external and internal requirements, e.g. from regulations or policies;
- security controls already implemented by the organization that support system development;
- trustworthiness of personnel working in the environment;
- the degree of outsourcing associated with system development;
- the need for segregation between different development environments;
- control of access to the development environment;
- monitoring of change to the environment and code stored therein;
- backups are stored at secure offsite locations; and,
- control over the movement of data from and to the environment.
- All software deployed on Corporate or Hosted infrastructure must prevent security issues including but not limited to those covered by SAN and OWASP.
- Code changes are reviewed by individuals other than the originating code author and by individuals who are knowledgeable in code review techniques and secure coding practices.
- Overrides of edit checks, approvals, and changes to confirmed transactions should be appropriately authorized, documented, and reviewed.
- Application development activity should be separated from the production and test environments. The extent of separation, logical or physical, is recommended to be appropriate to the risk of the business application or be in line with customer contractual requirements. The level of separation that is necessary between production, development, and test environments should be evaluated and controls established to secure that separation.
- All changes to production environments should strictly follow change control procedures, including human approval of all changes, granted by an authorized owner of that environment. Automated updates should be disallowed without such approval.
- Active production environments should not be re-used as test environments. Inactive and/or decommissioned production environments should not be used as test environments unless all private data has been removed. Test environments should not be re-used as production environments without going through a decommissioning and recommissioning process that cleans all remnants of test data, tools, etc.
- Individuals who are responsible for supporting or writing code for an internet-facing application, or internal application that utilizes web technology and handles customer information, should complete annual security training specific to secure coding practices. For individuals supporting or writing code for an internet-facing application, training should also include topics specific to internet threats. The individual should complete the training prior to writing or supporting the code. The training must include OWASP secure development principles as well as OWASP top 10 vulnerability awareness for the most recent year available.
- Custom accounts and user IDs and/or passwords should be removed from applications before applications become active or are released to customers.
- Production data should not be used in testing or development environments.
- Security controls that are in place for the production copy in the test system should be production quality (e.g. mirroring the production controls over the data).
- When conducting quality assurance (QA) testing prior to the release of a new feature requiring user input where constraints on user input may be reasonably understood, feature acceptance tests must include testing of edge and boundary cases.
For situations demonstrating that testing needs to use production data, the requirements are the following:
- The Information Resource Owner will provide approval before production data can be used for testing purposes.
- Wherever possible, the production data should be tokenized or anonymized instead of using production data.
- Testing and parallel runs should use a separate copy of production data and the test location or destination should be acceptable (e.g. loading confidential production data to a laptop for testing is not acceptable).
- The data should not be extracted, handled, or used by the test process in a manner that subjects the data to unauthorized disclosure.
- The data should be accessed on a need-to-know basis.
- Normal test activities should not use production data. In cases where test activity requires access to production data, access to production data should be restricted to only those individuals who have a documented business need. Only the information with the documented business need should be accessible by those users.
- Production data used for testing should be securely erased upon completion of testing.
- Test data and accounts will be removed before being placed into production.
- Restricted/Protected Information will be encrypted according to the Encryption Standard while at rest or in transit.
- Error messages must be handled securely and they must not leak sensitive information.
If production is outsourced, the following will be considered, as applicable, across the entire external supply chain in conjunction with the requirements outlined in the Vendor Management Policy:
- Licensing arrangements, code ownership, and intellectual property rights related to the outsourced content.
- Contractual requirements for secure design, coding, and testing practices.
- Provision of the approved threat model to the external developer.
- Acceptance testing for the quality and accuracy of the deliverables.
- Provision of evidence that security thresholds were used to establish minimum acceptable levels of security and privacy quality.
- Provision of evidence that sufficient testing has been applied to guard against the absence of both intentional and unintentional malicious content upon delivery.
- Provision of evidence that sufficient testing has been applied to guard against the presence of known vulnerabilities.
- Escrow arrangements, e.g. if source code is no longer available.
- Contractual right to audit development processes and controls.
- Effective documentation of the build environment used to create deliverables.
- The organization remains responsible for compliance with applicable laws and control efficiency verification.
Software Installation and Change on Operational Systems
- Operating system applications and software will only be implemented after extensive and successful testing. The tests will cover:
- Effects on other systems
- Tests will be conducted on separate systems (test environment), and all corresponding program source libraries will also be updated, as appropriate.
- The operational software, applications, and program libraries of Collate will only be updated by trained administrators upon appropriate management authorization.
- Company operational systems will only hold approved executable code, not development code or compilers.
- A configuration control system will be used to keep control of all implemented software as well as the system documentation.
- Previous versions of the software will be retained as a contingency measure.
- Old versions of the software will be archived, together with all required information and parameters, procedures, configuration details, and supporting software for as long as the data are retained in the archive.
- There will be a rollback strategy in place before changes are implemented.
- An audit log will be maintained of all updates to operational program libraries.
- All decisions to upgrade to a new version release must take into account:
- Business requirements for the change
- Security of the release, e.g. the introduction of new information security functionality or the number and severity of information security problems affecting this version.
Change Control Procedures
- A record of agreed authorization levels will be maintained.
- Changes are only submitted by authorized users.
- Controls and integrity procedures will be reviewed to ensure that they will not be compromised by the changes.
- All software, information, database entities, and hardware that require amendment will be identified.
- Security critical code to minimize the likelihood of known security weaknesses will be identified and checked.
- Formal approval must be obtained for detailed proposals before work begins.
- Authorized users must accept changes prior to implementation.
- Changes will be implemented at a time that is least intrusive to business processes involved.
- Vendor-supplied software will be used without modification; in the event that a modification is necessary, the following will be evaluated:
- Risk of compromising built-in controls and integrity processes
- Vendor consent
- Getting the modifications from the vendor as standard updates
- Impact of owning the responsibility for maintaining the program
- Compatibility with other software in use.
- Risk of compromising built-in controls and integrity processes
- A technical review of applications will be conducted after changes to operating platforms (operating systems, databases and middleware platforms). The review will include:
- Application control and integrity procedures to ensure that they have not been compromised by the operating platform changes.
- Timely notification of operating platform changes to allow appropriate tests and reviews to take place before implementation.
- Appropriate changes are made to the business continuity plans.
13. System Access Control Policy
SOC 2 Criteria: CC6.2, CC6.3, CC6.4, CC6.5, P4.3
ISO 27001 Annex A: A.5.1.1, A.6.1.2, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.5, A.9.2.6, A.9.4.1, A.9.4.2, A.9.4.4, A.9.4.5, A.12.1.1, A.13.1.1, A.13.1.2
Keywords: Access, Least privilege principle, Least access principle, Role change, Access reviews
Access to Collate systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized use or access of the organization's information systems.
The purpose of this procedure is to provide a policy and guideline for creating, modifying, or removing access to the company’s network and data by creating, changing or deleting the network account configuration for a User.
This policy and defined process is used to allow access to the company’s data and systems to individuals who meet the requirements defined in this policy. This policy governs individuals who are granted access that is necessary to support the business. This policy relates to all data used, processed, stored, maintained, or transmitted in and through the company’s systems.
Access Establishment and Modification
Requests for access to Collate Platform systems and applications are made formally using the following process:
- A Collate workforce member initiates the access request by creating an Issue in the Collate ticketing system.
- User identities must be verified prior to granting access to new accounts.
- Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
- For new accounts, the method used to verify the user's identity must be recorded on the Issue.
- The Security Officer will grant or reject access to systems as dictated by the employee's job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
- If the request is rejected, it goes back for further review and documentation.
- If the review is approved, the request is marked as “Done”, and any pertinent notes are added.
All access to Collate systems and services is reviewed and updated on monthly basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:
- The Security Officer initiates the review of user access by creating an Issue in the Collate Ticketing System
- The Security Officer is assigned to review levels of access for each Collate workforce member.
- If user access is found during review that is not in line with the least privilege principle, the Security Officer may modify user access and notify the user of access changes.
- Once the review is complete, the Security Officer then marks the ticket as “Done”, adding any pertinent notes required.
- The level of security assigned to a user to the organization's information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user's job classification.
- All access requests are treated on a "least-access principle."
- Collate maintains a minimum necessary approach to access to Customer data.
Unique User Identification
- Access to the Collate Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
- Passwords requirements mandate strong password controls.
- Passwords are not displayed at any time and are not transmitted or stored in plain text.
- Default accounts on all production systems, including root, are disabled.
- Shared accounts are not allowed within Collate systems or networks.
- Automated log-on configurations other than the company’s approved Password Management provider that store user passwords or bypass password entry are not permitted for use with Collate workstations or production systems.
Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
Employee Workstation Use
All workstations at Collate are company owned, and all are laptop products running Windows, Mac OSX or Linux.
- Workstations may not be used to engage in any activity that is illegal or is in violation of organization's policies.
- Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or "X-rated". Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual's race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through the organization's system.
- Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization's best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
- Solicitation of non-company business, or any use of organization's information systems/applications for personal gain is prohibited.
- Users may not misrepresent, obscure, suppress, or replace another user's identity in transmitted or stored messages.
- Workstation hard drives must be encrypted
- All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.
Employee Termination/Offboarding Procedures
- The Human Resources Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitate completion of the "Termination Checklist".
- The Human Resources Department, users, and supervisors are required to notify the Security Officer to terminate a user's access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
- The user has been using their access rights inappropriately;
- A user's password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
- The Security Officer will terminate users' access rights within one day of termination/separation, and will coordinate with the appropriate Collate employees to terminate access to any non-production systems managed by those employees
- The Security Officer audits and may terminate access of users that have not logged into the organization's information systems/applications for an extended period of time.
14. Vendor Management Policy
SOC 2 Criteria: CC2.3, CC3.2, CC3.3, CC3.4, CC4.1, CC4.2, CC6.4, CC9.2, P6.2, P6.4 ISO 27001 Annex A: A.15.1.1, A.15.1.2, A.15.1.3, A.15.2.1, A.15.2.2
Keywords: Vendors, SOC report review, 3rd party applications, Vendor contracts
The purpose of this policy is to establish requirements for ensuring third-party service providers/vendors meet Collate requirements for preserving and protecting Collate information.
The policy applies to all IT vendors and partners who have the ability to impact the confidentiality, integrity, and availability of Collate’s technology and sensitive information, or who are within the scope of Collate’s information security program. This policy also applies to all employees and contractors that are responsible for the management and oversight of IT vendors and partners of Collate.
This policy prescribes the minimum standards a vendor must meet from an information security standpoint, including security clauses, risk assessments, service level agreements, and incident management.
Roles and Responsibilities
Collate makes every effort to ensure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of Collate or its customer data. 3rd parties include customers, partners, subcontractors, and contracted developers.
- IT vendors are prohibited from accessing Collate’s information security assets until a contract containing security controls is agreed to and signed by the appropriate parties.
- All IT vendors must comply with the security policies defined and derived from Collate’s Information Security Program to include the Acceptable Use Policy.
- IT vendors and partners must ensure that organizational records are protected, safeguarded, and disposed of securely. Collate strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII).
- Collate may choose to audit IT vendors and partners to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.
An inventory of third party service providers shall be maintained, and the inventory will include:
- Vendor risk level
- Types of data shared with the third party
- Brief description of services
- Main point of contact at the third party
- How access is granted to the third party vendor
- Significant controls in place
- Security report and/or questionnaire
Vendor risk level assessment will be based on the following considerations:
- High : the vendor stores or has access to sensitive data and a failure of this vendor would have critical impact on your business
- Moderate : the vendor does not store or have access to sensitive data and a failure of this vendor would not have critical impact on your business
- Low : the vendor doesn't store or have access to any data and a failure of this vendor would have very little to no impact on your business
Formal contracts that address relevant security and privacy requirements must be in place for all third parties that process, store, or transmit confidential data or provide critical services.
The following must be included in all such contracts:
- Contracts will acknowledge that the third party is responsible for the security of the institution’s confidential data that it possesses, stores, processes, or transmits;.
- Contracts stipulate that the third-party security controls are regularly reviewed and validated by an independent party;.
- Contracts identify information security policies relevant to the agreement.
- Contracts establish training and awareness requirements for specific procedures and information security requirements.
- Contracts identify relevant regulations for sub-contracting.
- Contracts implement a monitoring process and acceptable methods for validating the adherence to security requirements of delivered information and communication technology products and services.
- Contracts implement specific processes for managing information and communication technology component lifecycle and availability and associated security risks.
- Contracts identify and outline use of key controls to ensure the protection of organizational assets – e.g. physical controls, controls for protection against malicious code, physical protection controls, controls to protect integrity, availability and confidentiality of information, controls to ensure the return or destruction of information assets after their use, controls to prevent copying and distributing information.
- Contracts define information security requirements and identify the owner of information and how intellectual property rights are regulated.
- Contracts identify the recourse available to Collate should the third party fail to meet defined security requirements.
- Contracts establish responsibilities for responding to direct and indirect security incidents including timing as defined by service-level agreements (SLAs).
- Contracts specify the security requirements for the return or destruction of data upon contract termination.
- Responsibilities for managing devices (e.g., firewalls, routers) that secure connections with third parties are formally documented in the contract.
- Contracts stipulate geographic limits on where data can be stored or transmitted.
Vendor Services Change Management
Changes to the provision of services by vendors, including maintaining and improving existing information security policies, procedures and controls, should be managed, taking account of business information criticality, systems and processes involved and re-assessment of risks. The following aspects will be considered:
- Changes to supplier agreements;
- Changes made by the organization to implement:
- Enhancements to the current services offered;
- Development of any new applications and systems;
- Modifications or updates of the organization’s policies and procedures;
- New/changed controls to resolve security incidents and improve security.
- Changes in supplier services to implement:
- Changes and enhancement to networks;
- Use of new technologies;
- Adoption of new products or newer versions/releases;
- New development tools and environments;
- Changes to physical location of service facilities;
- Change of suppliers;
- Subcontracting to another supplier.
15. Vulnerability Management Policy
SOC 2 Criteria: CC1.2, CC3.1, CC3.3, CC3.4, CC4.1, CC4.2, CC5.1, CC5.2, CC7.1, CC7.2 ISO 27001 Annex A: A.12.1.1, A.12.7.1, A.18.2.3
Keywords: Penetration testing, Pen testing, Vulnerability scans, Vulnerability priority levels, Security SLAs
Collate policy requires that:
- All product systems must be scanned for vulnerabilities at least annually.
- All vulnerability findings must be reported, tagged, and tracked to resolution in accordance with the SLAs defined herein. Records of findings must be retained for at least 1 year.
Roles and Responsibilities
Information Systems Audit
The following guidelines will be observed for setting information systems audit controls:
- Audit requirements for access to systems and data should be agreed upon with appropriate management.
- The scope of technical audit tests should be agreed upon and controlled.
- Audit tests should be limited to read-only access to software and data.
- Access other than read-only should only be allowed for isolated copies of system files, which should be erased when the audit is completed, or given appropriate protection if there is an obligation to keep such files under audit documentation requirements.
- Requirements for special or additional processing should be identified and agreed upon.
- Audit tests that could affect system availability should be run outside business hours.
- All access should be monitored and logged to produce a reference trail.
Vulnerability Scanning and Infrastructure Security Testing
The scanning and identification of Collate’s system vulnerabilities is performed by:
- Automated Drata security agent installed on all employees’ machines.
- Snyk is used to scan the version control repositories.
Penetration testing is performed regularly by either a certified penetration tester on Collate’s security team or an independent third party.
Findings from a vulnerability scan and/or penetration test are analyzed by the Security Officer, together with IT and Engineering as needed, and reported through the process defined in the next section.
Security Findings Reporting, Tracking, and Remediation
Collate follows a simple vulnerability tracking process using Github Issues privately tracked. The records of findings are retained for 1 year.
Reporting a Finding
- Upon identification of a vulnerability (including a allowand vulnerability in software, system, or process), a Github ticket is created.
- The description of the Finding should include further details, without any confidential information, and a link to the source.
- The Finding will be given a priority level in Github ticket
Priority/Severity Ratings and Service Level Agreements
In an effort to quickly remediate security vulnerabilities, the following timelines have been put in place to address vulnerabilities:
|Critical||1 day||Vulnerabilities that cause a privilege escalation on the platform from unprivileged to admin, allows remote code execution, financial theft, unauthorized access to/extraction of sensitive data, etc.||Vulnerabilities that result in Remote Code Execution such as Vertical Authentication bypass, SSRF, XXE, SQL Injection, User authentication bypass of sensitive data, etc. authentication bypass|
|High||1 week||Vulnerabilities that affect the security of the platform including the processes it supports.||Lateral authentication bypass, Stored XSS, some CSRF depending on impact|
|Medium||1 Month||Vulnerabilities that affect multiple users, and require little or no user interaction to trigger||Reflective XSS, Direct object reference, URL Redirect, some CSRF depending on impact|
|Low||3 Months||Issues that affect singular users and require interaction or significant prerequisites (MitM) to trigger.||Common flaws, Debug information, Mixed Content|
In the case a severity rating and/or priority level is updated after a vulnerability finding was originally created, the SLA is updated as follows:
- Priority upgrade: reset SLA from time of escalation
- Priority downgrade: SLA time remains the same from the time of creation/identification of finding
Resolving a Finding
- The Finding should be assigned to the owner responsible for the system or software package.
- All findings should be addressed according to the established SLA.
- No software should be deployed to production with unresolved CRITICAL or HIGH findings unless an Exception is in place (see below).
- A finding may be resolved by
- providing a valid fix/mitigation
- determining as a false positive
- documenting an approved exception
Closing a Finding
- The assignee should provide a valid resolution (see above) and add a comment to the finding.
- The finding should be re-assigned to the Reporter or a member of the security team for validation.
- Upon validation, the finding can be marked as Done (closed) by the Reporter.
- Before the finding can be marked as closed by the reporter, the fix must be deployed to a development environment and have a targeted release date for deploying to production noted on the ticket.
- An Exception may be requested when a viable or direct fix to a vulnerability is not available. For example, a version of the package that contains the fix is not supported on the particular operating system in use.
- An alternative solution (a.k.a. compensating control) must be in place to address the original vulnerability such that the risk is mitigated. The compensating control may be technical or a process or a combination of both.
- An Exception must be opened in the form of a Github ticket
- The Exception Issue must reference the original Finding by adding an Issue Link to the Finding issue.
- Each Exception must be reviewed and approved by the Security Officer and the impacted asset owner.
16. Encryption Policy
SOC 2: CC6.7
ISO 27001 Annex A: A.10.1.1, A.10.1.2, A.14.1.2, A.18.1.5
Keywords: Encryption key management
This policy defines organizational requirements for the use of cryptographic controls, as well as the requirements for cryptographic keys, in order to protect the confidentiality, integrity, authenticity, and nonrepudiation of information.
This policy applies to all systems, equipment, facilities, and information within the scope of Collate’s information security program. All employees, contractors, part-time, and temporary workers, service providers, and those employed by others to perform work on behalf of the organization related to cryptographic systems, algorithms, or keying material are subject to this policy and must comply with it.
This policy defines the high-level objectives and implementation instructions for Collate’s use of cryptographic algorithms and keys. It is vital that the organization adopt a standard approach to cryptographic controls across all work centers in order to ensure end-to-end security, while also promoting interoperability. This document defines the specific algorithms approved for use, requirements for key management and protection, and requirements for using cryptography in cloud environments.
Roles and Responsibilities
Collate must protect individual systems or information by means of cryptographic controls as defined in Table 3: Table 3: Cryptographic Controls
|Name of System/Type of Information||Cryptographic Tool||Encryption Algorithm||Key Size|
|Public Key Infrastructure (PKI) for Authentication||OpenSSL||AES-256||256-bit key|
|Data Encryption Keys||OpenSSL||AES-256||256-bit key|
|Virtual Private Network (VPN) keys||OpenSSL and OpenVPN||AES-256||256-bit key|
|Website SSL Certificate||OpenSSL, CERT||AES-256||256-bit key|
When required, customers of Collate’s cloud-based software platform offering must be able to obtain information regarding:
- The cryptographic tools used to protect their information.
- Any capabilities that are available to allow cloud service customers to apply their own cryptographic solutions.
- The identity of the countries where the cryptographic tools are used to store or transfer cloud service customers’ data.
The use of organizationally-approved encryption must be governed in accordance with the laws of the country, region, or other regulating entity in which users perform their work. Encryption must not be used to violate any laws or regulations including import/export restrictions. The encryption used by Collate conforms to international standards and U.S. import/export requirements and thus can be used across international boundaries for business purposes.
Except where otherwise stated, keys must be managed by their owners. Cryptographic keys must be protected against loss, change or destruction by applying appropriate access control mechanisms to prevent unauthorized use and backing up keys on a regular basis.
Key Management Service
All key management must be performed using software that automatically manages key generation, access control, secure storage, backup, and rotation of keys. Specifically:
- The key management service must provide key access to specifically-designated users, with the ability to encrypt/decrypt information and generate data encryption keys.
- The key management service must provide key administration access to specifically-designated users, with the ability to create, schedule delete, enable/disable rotation, and set usage policies for keys.
- The key management service must store and backup keys for the entirety of its operational lifetime.
- The key management service must rotate keys at least once every 12 months.
Keys used for secret key encryption (symmetric cryptography), must be protected as they are distributed to all parties that will use them.
- During distribution, the symmetric encryption keys must be encrypted using a stronger algorithm with a key of the longest key length for that algorithm.
- If the keys are for the strongest algorithm, then the key must be split, each portion of the key encrypted with a different key that is the longest key length authorized, and each encrypted portion is transmitted using different transmission mechanisms.
Symmetric encryption keys, when at rest, must be protected with security measures at least as stringent as the measures used for the distribution of that key.
Public key cryptography (asymmetric cryptography), uses public-private key pairs. The public key is passed to the certificate authority to be included in the digital certificate issued to the end-user. The digital certificate is available to everyone once it is issued. The private key should only be available to the end-user to whom the corresponding digital certificate is issued.
PGP Key Pairs
If the business partner requires the use of PGP, the public-private key pairs can be stored in the user’s keyring files on the computer hard drive or on a hardware token, for example, a USB drive or a smart card. Since the protection of the private keys is the passphrase on the secret keying, it is preferable that the public-private keys are stored on a hardware token. PGP will be configured to require entering the passphrase for every use of the private keys in the secret keyring.
Hardware Token Storage
Hardware tokens storing encryption keys will be treated as sensitive company equipment, as described in Collate’s Physical Security Policy, when outside company offices.
All hardware tokens, smartcards, USB tokens, etc., will not be stored or left connected to any end user’s computer when not in use.
For end users traveling with hardware tokens, they will not be stored or carried in the same container or bag as any computer.
Personal Identification Numbers (PINs), Passwords, and Passphrases
All PINs, passwords, or passphrases used to protect encryption keys must meet the complexity and length requirements described in Collate’s Password Policy.
Loss and Theft
The loss, theft, or potential unauthorized disclosure of any encryption key covered by this policy must be reported immediately.
17. Business Continuity Plan
SOC 2 Criteria: CC5.3, CC7.5
ISO 27001 Annex A: A.17.1.1, A.17.1.2, A.17.1.3
Keywords: BIA, Status Page, Worksite Recovery
This policy establishes procedures to recover Collate following a disruption in conjunction with the Disaster Recovery Plan.
Collate policy requires that:
- A plan and process for business continuity, including the backup and recovery of systems and data, must be defined and documented.
- The Business Continuity Plan shall be simulated and tested at least once a year. Metrics shall be measured and identified recovery enhancements shall be filed to improve the process.
- Security controls and requirements must be maintained during all Business Continuity Plan activities.
Roles and Responsibilities
This Policy is maintained by the CTO and Security Team. All executive leadership shall be informed of any and all contingency events.
Line of Succession
The following order of succession ensures that decision-making authority for the Collate Business Continuity Plan is uninterrupted. The CEO is responsible for ensuring the safety of personnel and the execution of procedures documented within this Plan. The Head of Engineering is responsible for the recovery of Collate technical environments. If the CEO or Head of Engineering is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the Business Operations Lead shall function as that authority or choose an alternative delegate.
Response Teams and Responsibilities
The following teams have been developed and trained to respond to a contingency event affecting Collate infrastructure and systems.
- HR & Facilities is responsible for ensuring the physical safety of all Collate personnel and environmental safety at each Collate physical location. The team members also include site leads at each Collate work site. The team leader is the Head of HR who reports to the CEO.
- DevOps is responsible for assuring all applications, web services, platforms, and their supporting infrastructure in the Cloud. The team is also responsible for testing re- deployments and assessing damage to the environment. The team leader is the Head of Engineering.
- Security is responsible for assessing and responding to all cybersecurity-related incidents according to Collate Incident Response policy and procedures. The security team shall assist the above teams in recovery as needed in non-cyber security events. The team leader is the Security Officer.
Members of the above teams must maintain local copies of the contact information of the Business Continuity Plan succession team. Additionally, the team leads must maintain a local copy of this policy in the event Internet access is not available during a disaster scenario.
All executive leadership shall be informed of any and all contingency events.
Business Impact Analysis (BIA)
The BIA will help identify and prioritize system components by correlating them to the business processes that the system supports. It will allow for the characterization of the impact on the processes if the system becomes unavailable. The BIA has three steps:
- Determine business processes and recovery criticality. business processes supported by the system are identified and the impact of a system disruption on those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum that an organization can tolerate while still maintaining the mission.
- Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
- Identify recovery priorities for system resources. Based on the results from the previous activities, system resources can more clearly be linked to critical mission/business processes. Priority levels can be established for sequencing recovery activities and resources.
See Appendix A for the BIA breakdown
Work Site Recovery
Collate is a fully remote company, and the employees have the ability to work from any location with Internet access and do not require an office-provided Internet connection.
Application Service Event Recovery
Collate maintains a status page to provide real-time updates and inform customers of the status of each service. The status page is updated with details about an event that may cause service interruption/downtime. Collate’s status page:
Business Impact Analysis
Collate, and its employees operate remotely. Collate provides a SaaS offering of its products and is deployed on AWS in multiple regions. Collate uses Gsuite and Slack for its employees to connect and collaborate
STEP 1. Determine Process and System Criticality
Identify the specific business processes that depend on or support the information system, using input from users, managers, business process owners, and other internal or external points of contact.
|Infrastructure - AWS||AWS is Collate's infrastructure to offer the SaaS product, and it's our infra for the core business.|
|Communications - Slack & Gsuite||Employees of Collate communicate through Slack in real time and for email, Gsuite is used real-time.|
|Communications - Collaboration & SSO||Employees of Collate use Gsuite for SSO, Email, and Docs|
Impact categories and values characterize levels of severity to the company that would result for that particular impact category if the business process could not be performed. These impact categories and values are samples and should be revised to reflect what is appropriate for the organization.
|<CAT 1>||<CAT 2>||<CAT 3>||<CAT 4>||IMPACT|
Downtime factors resulting from a disruptive event will be estimated by working directly with business process owners, departmental staff, managers, and other stakeholders. The following downtime categories will be considered:
- Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time managers are willing to accept for a business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave continuity planners with imprecise direction on:
- Selection of an appropriate recovery method; and
- The depth of detail which will be required when developing recovery procedures, including their scope and content.
- Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported business processes, and the MTD. Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.
- Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which business process data must be recovered (given the most recent backup copy of the data) after an outage.
STEP 2. Identify Resource Requirements
Identify the resources that compose
|SYSTEM RESOURCE/COMPONENT||PLATFORM/OS/VERSION (AS APPLICABLE)||DESCRIPTION|
STEP 3. Identify Recovery Priorities for System Resources
List the order of recovery for
Any alternate strategies in place to meet expected RTOs will be identified, including backup or spare equipment and vendor support contracts.
18. Data Classification Policy
SOC 2 Criteria: C1.1, PI1.1
ISO 27001 Requirements: 7.5.2, 7.5.3
ISO 27001 Annex A: A.5.1.1, A.7.1.2, A.7.2.1, A.8.1.1, A.8.2.1, A.8.2.2, A.16.1.4, A.18.1.3
Keywords: Confidential Data, Internal Data, Public Information, Restricted Data, Classification
This policy will assist employees and other third parties with understanding the Company’s information labeling and handling guidelines. It should be noted that the sensitivity level definitions were created as guidelines and to emphasize common-sense steps that you can take to protect sensitive or confidential information (e.g., Company Confidential information should not be left unattended in conference rooms).
Information covered in this policy includes, but is not limited to, information that is received, stored, processed, or transmitted via any means. This includes electronic, hardcopy, and any other form of information regardless of the media on which it resides.
Roles and Responsibilities
- Confidential/Restricted Data:
Generalized terms, which typically represent data classified as Sensitive or Private, according to the data classification scheme defined in this policy.
- Internal Data
All data owned or licensed by Collate.
- Public Information:
Any information that is available within the public domain.
Data Classification Scheme
Data classification, in the context of information security, is the classification of data based on its level of sensitivity and the impact to Collate should that data be disclosed, altered, or destroyed without authorization. The classification of data helps determine what baseline security controls are appropriate for safeguarding that data. All data should be classified into one of the three following classifications.
Data should be classified as Restricted or Confidential when the unauthorized disclosure, alteration, or destruction of that data could cause a serious or significant level of risk to Collate or its customers. Examples of Sensitive data include data protected by state or federal privacy regulations (e.g. PHI & PII) and data protected by confidentiality agreements. The highest level of security controls should be applied to Restricted and Confidential Data:
- Disclosure or access to Restricted and Confidential data is limited to a specific use by individuals with a legitimate need-to-know. Explicit authorization by the Security Officer is required for access because of legal, contractual, privacy, or other constraints.
- Must be protected to prevent loss, theft, unauthorized access, and/or unauthorized disclosure.
- Must be destroyed when no longer needed. Destruction must be in accordance with Company policies and procedures.
- Will require specific methodologies, procedures, and reporting requirements for the response and handling of incidents.
Internal Use Data
Data should be classified as Internal Use when the unauthorized disclosure, alteration, or destruction of that data could result in a moderate level of risk to Collate or its customers. This includes proprietary, ethical, or privacy considerations. Data must be protected from unauthorized access, modification, transmission, storage or other use. This applies even though there may not be a civil statute requiring this protection. Internal Use Data is restricted to personnel who have a legitimate reason to access it. By default, all data that is not explicitly classified as Restricted/Confidential or Public data should be treated as Internal Use data. A reasonable level of security controls should be applied to Internal Use Data.
Data should be classified as Public when the unauthorized disclosure, alteration, or destruction of that data would result in little or no risk to Collate and its customers. It is further defined as information with no existing local, national, or international legal restrictions on access or usage. While little or no controls are required to protect the confidentiality of Public data, some level of control is required to prevent unauthorized alteration or destruction of Public Data.
Assessing Classification Level and Labeling
The goal of information security, as stated in the Information Security Policy, is to protect the confidentiality, integrity, and availability of Corporate and Customer Data. Data classification reflects the level of impact to Collate if confidentiality, integrity, or availability is compromised. If a classification is not inherently obvious, consider each security objective using the following table as a guide. All data are to be assigned one of the following four sensitivity levels:
DATA CLASSIFICATION DESCRIPTION
Restricted information is highly valuable, highly sensitive business information and the level of protection is dictated externally by legal
and/or contractual requirements. Restricted information must be limited to only authorized employees, contractors, and business partners with a specific business need.
Potential Impact of Loss
SIGNIFICANT DAMAGE would occur if Restricted information were to become available to unauthorized parties either internal or external to Collate. Impact could include negatively affecting Collate’s competitive position, violating regulatory requirements, damaging the company’s reputation, violating contractual requirements, and posing an identity theft risk
Confidential information is highly valuable, sensitive business the information,tamper-resistanttamper-resistant and the level of protection is dictated internally by Collate.
Potential Impact of Loss
SIGNIFICANT DAMAGE would occur if Confidential information were to become available to unauthorized parties either internal or
external to Collate. Impact could include negatively affecting Collate’s competitive position, damaging the company’s reputation, violating
contractual requirements, and exposing geographic location of individuals.
Internal Use information is information originating within or owned by Collate, or entrusted to it by others. Internal Use information may be
shared with authorized employees, contractors, and business partners
who have a business need, but may not be released to the general public, due to the negative impact it might have on the company’s business interests.
Potential Impact of Loss
MODERATE DAMAGE would occur if Internal Use information were to become available to unauthorized parties either internal or external to Collate. Impact could include damaging the company’s reputation and violating contractual requirements.
Public information is information that has been approved for release to the general public and is freely shareable both internally and externally.
Potential Impact of Loss
NO DAMAGE would occur if Public information were to become available to parties either internal or external to Collate. Impact would not be damaging or a risk to business operations.
HANDLING CONTROLS PER DATA CLASSIFICATION
Non-Disclosure Agreement (NDA)
- NDA is required prior to access by non-Collate employees.
- NDA is recommended prior to access by non-Collate employees.
- No NDA requirements
- No NDA requirements
Transmission (wired &
- No special requirements
-No special requirements
Transmission (wired &
- No special requirements
Data at Rest (file servers, databases, archives,
Mobile Devices (iPhone,
iPad, USB Drive, etc.)
- No special requirements
Email (with and without attachments)
- No special requirements
- No special requirements
19. Incident Response Plan
SOC 2 Criteria: CC2.2, CC2.3, CC4.2, CC5.1, CC7.3, CC7.5, CC9.1 ISO 27001 Annex A: A.16
Keywords: Impact, Security impact level, Report template, Incident
This security incident response policy is intended to establish controls to ensure the detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.
This document also provides implementing instructions for security incident response, including definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).
This policy applies to all users of information systems within Collate. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by Collate (hereinafter referred to as “users”). This policy must be made readily available to all users.
A key objective of Collate’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. Collate is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches are likely to happen; when they do, Collate is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving, and communicating information related to the breach.
This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, Collate must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time-based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners, and other stakeholders.
Within this document, the following definitions apply:
- Information Security Vulnerability:
A vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.
- Information Security Incident:
A suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.
Roles and Responsibilities
- All users must report any system vulnerability, incident, or event pointing to a possible incident to the Security Officer as quickly as possible but no later than 24 hours.
- Incidents must be reported by sending an email message with details of the incident.
- Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to the Human Resources (HR) Manager for disciplinary action.
- Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.
- All information security incidents must be responded to through the incident management procedures defined below.
It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding Collate's expectations from them, relative to security responsibilities. The incident response plan is tested annually.
Procedure For Establishing Incident Response System:
- Define the on-call schedule and assign an Information Security Manager (ISM) responsible for managing incident response procedures during each availability window.
- Define a notification channel to alert the on-call ISM of a potential security incident. Esnumberstablish a company resource that includes up-to-date contact information for on-call ISM.
- Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.
- Distribute Procedure For Executing Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource.
- Require all staff to complete training for Procedure For Executing Incident Response at least once per year.
The following situations are to be considered for information security event reporting:
- Ineffective security control;
- Breach of information integrity, confidentiality, or availability expectations;
- Human errors;
- Non-compliances with policies or guidelines;
- Breaches of physical security arrangements;
- Uncontrolled system changes;
- Malfunctions of software or hardware;
- Access violations; and,
- Malfunctions or other anomalous system behavior indicative of a security attack or actual security breach.
Procedure For Executing Incident Response:
When an information security incident is identified or detected, users must notify their immediate manager within 24 hours. The manager must immediately notify the ISM on call for proper response. The following information must be included as part of the notification:
- Description of the incident
- Date, time, and location of the incident
- The person who discovered the incident
- How the incident was discovered
- Known evidence of the incident
- The affected system(s)
Within 48 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to Collate and assign a severity level, which will determine the level of remediation effort required:
- High: the incident is potentially catastrophic to Collate and/or disrupts Collate’s day-to-day operations; a violation of legal, regulatory, or contractual requirements is likely.
- Medium: the incident will cause harm to one or more business units within Collate and/or will cause delays to a business unit’s activities.
- Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.
The ISM, in consultation with management sponsors, shall determine appropriate incident response activities in order to contain and resolve incidents.
The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.
If the incident is deemed as High or Medium, the ISM must work with the VP of Brand/Creative, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to users, the public, and others affected.
The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in Collate’s incident log, and must contain the following:
- Description of the incident
- Incident severity level
- The root cause (e.g. source address, website malware, vulnerability)
- Mitigations applied (e.g. patch, re-image)
- Status (open, closed, archived)
- Disclosures (parties to which the details of this incident were disclosed, such as customers, vendors, law enforcement, etc.)
After an incident has been resolved, the ISM must conduct a post-mortem that includes root cause analysis and documentation of any lessons learned.
Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.
The ISM must notify all users of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed malicious.
Appendix A: Security Incident Report Template
1.0 Reported By
1.1 Last Name:
1.2 First Name:
1.4 Company/Org Name:
1.5 Telephone No:
2.0 Organization Details
2.1 Name of organization:
2.2 Type of organization:
2.3 Street Address:
2.4 At this time, is it known that other organizations are affected by this incident? (If so, list names, addresses, telephone number, email addresses,
and contact persons):
3.0 Incident Details including Injury and Impact Level
3.3 Location of affected site:
3.4 Brief summary of the incident (what
4.0 Status of Mitigation Actions
4.1 Mitigation details to date: (List any
actions that have been taken to mitigate the incident and by whom)
4.2 Results of mitigation:
4.3 Additional assistance required?
5.0 Computer Network Defense Incident Type (if applicable)
5.1 Malicious code: (Worm, virus, trojan, backdoor, rootkit, etc.)
5.2 Known vulnerability exploit: (List the Common Vulnerabilities and Exposures (CVE) number for known vulnerability)
5.3 Disruption of service:
5.4 Access violation: (Unauthorized access attempt, successful unauthorized access, password cracking, Etc.)
5.5 Accident or error: (Equipment failure, operator error, user error, natural or
5.6 If the incident resulted from user error or malfeasance, identify reasons (training, disregard for policy, other) and responsible parties
5.7 Additional details:
5.8. Apparent Origin of Incident or Attack
Source IP and port:
6.0 Systems Affected
6.1 Network zone affected: (Internet, administration, internal, etc.)
6.2 Type of system affected: (File server, Web server, mail server, database,
workstation (mobile or desktop), etc.)
6.3 Operating system (specify version):
6.4 Protocols or services:
6.5 Application (specify version):
7.0 Post Incident Activities
7.1 Has information contained in this report been provided to the authorities? When?
7.2 Complete a root cause analysis to determine the reason for the incident and steps to prevent re-occurrence.
20. Risk Assessment Policy
SOC 2 Criteria: CC3.1, CC1.2, CC2.1, CC3.1, CC3.2, CC3.3, CC3.4, CC4.1, CC4.2, CC5.1, CC5.2, CC5.3
ISO 27001 Requirements: 4.1, 6.1.2, 6.2, 8.2
ISO 27001 Annex A: A.5.1.1, A.10.1.1, A.16.1.4
Keywords: Risk assessment, Threat impact, Threat likelihood, Risk score, Risk remediation
The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within Collate, and to define the acceptable level of risk as set by Collate’s leadership.
Risk assessment and risk treatment are applied to the entire scope of Collate’s information security program, and to all assets which are used within Collate or which could have an impact on information security within it. This policy applies to all employees of Collate who take part in risk assessment and risk treatment.
A key element of Collate’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for Collate to identify information security risks. The process consists of four parts: identification of Collate’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.
- The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
- The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
- The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities.
- For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
- Once risk owners are identified, they must assess:
- Impact for each combination of threats and vulnerabilities for an individual asset if such a risk materializes.
- Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
- Criteria for determining impact and likelihood are defined in the tables below.
- The risk level is calculated by multiplying the impact score and the likelihood score.
Description of Impact Levels and Criteria:
game-changing loss of market share • Significant prosecution and fines, litigation including class actions, incarceration of leadership • Multiple senior leaders leave
Description of Likelihood Levels and Criteria:
Likelihood (Weight Factor)
Once in 100 years or less (<10% chance of occurrence over the life of
Risk Rating Criteria:
Low Risk: Less than or equal to 4.0
Medium Risk: Greater than 4.0 but less than or equal to 9.0
High Risk: Greater than 9.0 but less than or equal to 16.0
Critical Risk: Greater than 16.0
Risk Rating Matrix:
RISK SCORE MATRIX
1.0 x 1.0 = 1.0
1.0 x 2.0 =
1.0 x 3.0 = 3.0
1.0 x 4.0 =
1.0 x 5.0 =
2.0 x 1.0 = 2.0
2.0 x 2.0 =
2.0 x 3.0 = 6.0
2.0 x 5.0 =
3.0 x 1.0 = 3.0
3.0 x 2.0 =
3.0 x 3.0 = 9.0
3.0 x 4.0 =
3.0 x 5.0 =
4.0 x 1.0 = 4.0
4.0 x 2.0 =
4.0 x 3.0 =
4.0 x 4.0 =
4.0 x 5.0 =
5.0 x 1.0 = 5.0
5.0 x 2.0 =
5.0 x 3.0 =
5.0 x 4.0 =
5.0 x 5.0 =
- As part of this risk remediation process, the Company shall determine objectives for mitigating or treating risks. All high and critical risks must be treated. For continuous improvement purposes, company managers may also opt to treat medium and/or low risks for company assets.
- Treatment options for risks include the following options:
- Selection or development of security control(s).
- Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.
- Avoiding the risk by discontinuing the business activity that causes such risk.
- Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
- After selecting a treatment option, the risk owner should estimate the new impact and likelihood values after the planned controls are implemented.
Regular Reviews of Risk Assessment and Risk Treatment
The Risk Assessment Report must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year.
The results of risk assessments, and all subsequent reviews, shall be documented in a Risk Assessment Report.