Privacy Policy

Home/Privacy Policy

Privacy Policy

Respond Capture maintains an internal Information Security Management System (ISMS) certified to meet the standards of ISO/IEC 27701:2019. This section of the website contains Respond Capture's public-facing security documentation. While not all aspects of Respond Capture's ISMS are accessible to the public, this portion of the site includes documents shared in the interest of transparency.

Annual internal and external audits independently verify Respond Capture's commitment to implementing and maintaining comprehensive best-practice security processes, reinforcing the company’s reputation and public trust.

Sharing proprietary details about a security posture can expose potential vulnerabilities. Therefore, Respond Capture does not disclose any proprietary security information, except for details available in the Executive Summary of an audit and the policies shared in this section.

Each section within this site includes a "Last Updated" date at the bottom. This date indicates the most recent update to that specific page. Pages like this Introduction may be updated less frequently than policies and other reference materials.

Acceptable Use Policy (RC.8.1.24)

Objectives
To safeguard Respond Capture's information assets and systems, this Acceptable Use Policy is designed to protect both the company and individual users. The policy outlines the approved methods for accessing and utilizing systems and infrastructure in alignment with Respond Capture’s morals, ethics, and professional standards. This policy is not intended to restrict Respond Capture's culture of trust and integrity but to ensure individuals understand acceptable and unacceptable behaviors, thus preventing unintentional or deliberate exposure to risks or liabilities.

Scope
The Respond Capture Acceptable Use Policy applies to all employees, contractors, and third-party users of Respond Capture's information assets, systems, and resources provided to support Respond Capture's Applicant Tracking System.

General Statements
Respond Capture’s information assets will be classified based on their sensitivity. This classification will dictate how each asset is managed, processed, stored, protected, and disposed of, following the Respond Capture ISMS and Information Handling & Classification Policy.
Information systems and other resources provided by Respond Capture are primarily for authorized company purposes. Limited personal use of company equipment and resources is allowed, provided it adheres to this Acceptable Use Policy and Technology Manager guidelines, and does not involve accessing or attempting to access any information assets handled on behalf of Respond Capture or its clients/users.
Users are prohibited from accessing company information assets for activities other than their legitimate business purposes. Any modification, copying, deletion, or transmission of Respond Capture’s information must strictly follow the published policies and procedures governing legitimate business activities.
Users must not engage in activities that interfere with other authorized users' legitimate access or activities or that could result in denial of service to others.
Users are also forbidden from participating in any activity illegal under international, national, or local laws. If a conflict arises between such legislation and any part of this Acceptable Use Policy, it must be promptly referred to Senior Management for investigation and resolution.
Acceptable use prohibits the creation, processing, downloading, storage, sharing, or communication of any material deemed offensive by Respond Capture. This includes, but is not limited to, content involving:

Sexual images, language, or suggestive behavior
Racial or ethnic commentary or opinions
Gender-specific commentary or opinions
Offensive or derogatory comments about a person’s age, sexual orientation, marital or partnership status, religious beliefs, political beliefs, national or ethnic origin, or disability.

Respond Capture will promptly respond to requests for information arising from criminal investigations and legal proceedings, including electronically stored information. The company reserves the right to access its information systems and connected data repositories to inspect, review, store, or retrieve data at any time.
Respond Capture has the right to monitor employees', contractors', and third-party users' access to and use of information assets, systems, email and voicemail message repositories, and other resources provided by Respond Capture for conducting business activities.
This policy applies to all Respond Capture infrastructure, including but not limited to hardware assets (servers, desktop computers, laptops, mobile phones, and tablets), software assets (operating systems and application software), storage assets (magnetic/optical media and USB devices), and network infrastructure usage.
If this policy does not cover a specific issue, it should be referred to Senior Management for consideration and approval before the activity is undertaken.
Employees found in violation of this policy will be subject to disciplinary action, which may include termination of employment with Respond Capture. Contractors or third-party users found in violation will be dealt with appropriately, potentially leading to the termination of their engagement or formal escalation to their organization.

Acceptable Use of Computers and Information Systems
All information systems and related resources must be protected by passwords that adhere to the Respond Capture Password Management Policy and other relevant security controls as outlined in the system's risk assessment. These systems should automatically lock after a defined period of inactivity, or users should manually lock them when not in use.

Users are only authorized to access systems and resources they have specific permission to use. Any attempt to bypass security controls, access unauthorized data, or use another user’s account will result in disciplinary action. Users are strictly prohibited from attempting to hack into systems, data sources, or other websites, whether internally or externally, and must comply with the Respond Capture Access Control Policy at all times.

All information systems and related resources should be protected by antivirus software and other tools designed to safeguard their normal operations from unauthorized amendments or interference by malicious code. Operating systems and software applications should be promptly updated with patches provided by the vendor, following a proper evaluation to ensure vulnerabilities are addressed permanently. Antivirus software and other protective tools should be reviewed regularly to ensure they provide adequate protection against the latest threats. Users covered by this policy must always comply with the Respond Capture Malware Policy.

Users must cooperate and comply with instructions issued by Respond Capture regarding hardware device firmware upgrades when necessary to ensure ongoing secure operations.

Respond Capture information systems and resources should not be used to download, process, store, or transmit any material that Respond Capture considers obscene, threatening, abusive, offensive, defamatory, indecent, racist, sexist, libelous, hateful, or connected to illegal activities. Acts that breach copyright, trade secrets, or violate intellectual property rights are also forbidden.

Respond Capture's network infrastructure is to be used solely for its intended purposes. Users must not modify or disrupt any network connectivity or deliberately engage in any activity that increases network traffic to the extent that it disrupts normal operations. The use of Respond Capture network resources for non-commercial data transfer is limited to "reasonable" personal use as defined in this Policy. Respond Capture continuously monitors and records all network activity.

All software assets intended for installation on Respond Capture systems must undergo formal change management approval. Software will only be authorized if:

It has been thoroughly evaluated for information security vulnerabilities.
It has received specific authorization from change management for installation.
The company holds a valid software license for the intended installation.
The software is installed strictly according to the vendor’s license.
The company can support the software with necessary updates and security patches.

Respond Capture reserves the right to monitor and audit instances of installed software on its assets and systems. Any attempt by users to interfere with such monitoring or audits will result in disciplinary action.

Personal external storage devices, including external hard drives, USB memory sticks, and memory cards, are not permitted to connect to any Respond Capture system without prior permission from Senior Management, issued against a valid business requirement. Depending on the specific request and the permission granted, sensitive or protectively marked information must be encrypted as defined in the Information Classification and Handling Policy. Any such data must be securely and permanently removed, with the device cleansed to acceptable levels at the earliest opportunity. Simple file deletion is not acceptable for this purpose.

Users must maintain awareness of the offenses covered by the Computer Misuse Act 1990, which prohibits illegal access to computer systems without authority and the unauthorized introduction of software into a computer system with the intent to affect its normal operation or interfere with stored data or programs.

Acceptable Use of Mobile Devices
Users of Respond Capture-issued mobile devices, including laptops, mobile phones, and Personal Electronic Devices (PEDs), must comply with documented requirements detailing their access, use, storage, and protection. Such devices must be protected by passwords that comply with the Respond Capture Password Management Policy. Any actual or suspected loss, theft, or misuse must be reported promptly as an Information Security Incident.

Information stored on mobile devices should be kept to a minimum to reduce risk exposure and liability in the event of loss, theft, misuse, or damage. Any data stored on mobile devices must be encrypted according to the Information Classification and Handling Policy and Cryptographic Control Policy. If encryption is not technically possible, data storage is not permitted. Users must periodically review the device to purge all unnecessary or outdated data.

Personally owned mobile devices, such as laptops and smartphones, may only be used for Respond Capture business or connected to Respond Capture resources in strict compliance with the LTG Bring Your Own Device Policy.

The use of mobile phones must adhere to the Acceptable Use of Telephony Systems section of this Policy.

Acceptable Use of Email Systems
Respond Capture allows reasonable use of its email facilities for personal use, subject to Technology Director approval. All personal use of email will be processed, stored, and screened as if it were business communication and may be inspected as needed. The company reserves the right to restrict personal use of email systems at any time.

Users must be aware of the risks associated with opening emails or email attachments that may be infected with viruses or other malware. Users must always comply with the Respond Capture Malware Policy. When opening a Word or Excel document requesting "macros to be enabled," users should select "no" unless the macro is from a trusted source and the content is expected.

All Respond Capture-authored emails must undergo a classification review by the email author before transmission to ensure proper security classification and handling procedures are followed in accordance with the Information Classification & Handling Policy.

Respond Capture email systems must not be used for:

Commercial ventures unrelated to the company, including sending spam or bulk email messages.
The transmission or receipt of messages containing "offensive material," as defined in this Policy.
Sending communications that may be considered harassment due to their content or frequency.

Users of Respond Capture email systems for work-related purposes or when posting information to work-related forums or discussion groups must ensure that:

Communications are addressed correctly to minimize the risk of non-delivery or accidental misrouting.
Only information authorized for public domain disclosure is sent unless the recipient is bound by a non-disclosure agreement.
Information that discloses Respond Capture locations, operations, or employee or client information should not be sent unless the recipient is bound by a non-disclosure agreement covering the intended purpose of the email.
Any posting or opinions expressed in work-related forums or discussion groups should clearly state that the views do not reflect Respond Capture's position or opinion unless specifically authorized by the Chief Executive Officer.
Users conduct themselves with professionalism, courtesy, and integrity, in alignment with Respond Capture's corporate standards.
All messages or posts comply with copyright and intellectual property rights.

Acceptable Use of Internet & Web-Based Groups
Access to the internet is provided primarily for authorized business purposes and for conducting normal Respond Capture business. Reasonable personal use of this facility is permitted. Users must not access, attempt to access, or perform search activities for websites containing "offensive material," as defined in this Acceptable Use Policy.

Software, including tools and utilities, must not be downloaded from the internet to Respond Capture information systems without prior agreement from Change Management, following the procedures outlined in the Acceptable Use of Computers and Information Systems section and approval of an OTS Software Registration Form.

Acceptable Use of Telephony Systems
Respond Capture telephone systems, including fax facilities, are provided primarily for authorized business purposes and for conducting normal Respond Capture business. A reasonable number of personal calls are permitted with Manager approval. Users should keep personal calls brief, prefer landline destinations over mobiles where possible, and avoid making international calls unless for business reasons.

Responsibilities
All individuals covered by this Acceptable Use Policy are responsible for complying with every aspect of the policy. The requirement to comply with Respond Capture's policies is included within the Terms and Conditions of Employment and noted in each individual’s job specification.

The Technology Director and Personnel Manager are responsible for handling breaches of this Acceptable Use Policy, including initiating disciplinary actions where necessary.

Access Control Policy (RC8.2.24)

Objectives
All information assets, along with their supporting resources, must be protected to maintain their confidentiality, integrity, and availability at acceptable levels. This includes implementing appropriate controls to prevent loss, unauthorized access, unauthorized modification, and both deliberate and accidental damage.

Scope
Respond Capture's Access Control Policy encompasses the following:

Information Assets
All information assets (data) owned by Respond Capture or entrusted to Respond Capture by clients or users under an agreement outlining Respond Capture’s responsibility for data, including but not limited to:

Information assets held, processed, or stored at Amazon Web Services facilities under accounts owned by Respond Capture, used to facilitate Respond Capture's product offerings.

Supporting Assets
All supporting assets (non-data) that, by direct or indirect association, are integral to ensuring the confidentiality, integrity, or availability of the information assets mentioned above, including:

Hardware (e.g., network infrastructure, laptop computers, desktop computers, storage infrastructure, and mobile devices)
Software (e.g., operating systems, commercially available software applications, and internally developed software by Respond Capture)
Respond Capture Personnel (e.g., permanent, temporary, full-time, and part-time employees, authorized contractors, and any third-party users of information systems)

Documentation and Records
All policies, processes, procedures, work instructions, and records related to the management, use, control, and disposal of the information assets and supporting assets detailed above.

Policy

General Access Control Policy Statements
Respond Capture operates under the principle that default permissions are set to “deny all,” and specific permissions are required to grant access, aligned with the individual’s role and legitimate business needs.

Each Asset Owner is responsible for reviewing, authorizing, and documenting the details of individuals who have legitimate access to their assets. Access permissions should be reviewed regularly to ensure they remain accurate and up-to-date, with adjustments made as necessary.

All access and privileges must be immediately revoked when an employee leaves the company. The same obligation applies to contractors and third-party users under their respective organizations.

The level of protection and access to an information asset must align with:

The business need for the individual to access the asset
The security classification of the asset
The security of the environment in which the information asset is accessed
The security clearance and competencies of the individuals requiring access
The requirements of the Respond Capture Acceptable Use Policy

All access controls should be configured and managed to record both successful and unsuccessful access attempts. These records should be regularly reviewed, and any suspicious activities must be logged as an Information Security Incident for prompt investigation.

Active sessions must be terminated when no longer needed, and any unattended equipment or login session must be locked to prevent unauthorized access.

User Identification and Authentication
All users accessing information assets electronically must be assigned a unique User ID by Respond Capture. This ID should be used exclusively to access the information assets for which the user has been specifically authorized and has an ongoing business need.

Users must not use generic User IDs to access information assets, nor should they use super-user accounts (e.g., supervisor or administrator privileges) unless such access is essential under the prevailing circumstances.

Users must ensure their User ID is supported by personal passwords that fully comply with the Respond Capture Password Management Policy.

Remote Access Policy for Internal Users
Respond Capture ensures that all network connections to IT systems and information assets are always protected from unauthorized access while allowing legitimate connections by authorized internal users. Access requests must be reviewed by the asset owner, with records of granted access maintained and retained.

Remote access is only authorized via Respond Capture-owned equipment using pre-installed connection configurations (e.g., VPN). Users must not attempt to connect to Respond Capture networks or IT systems using non-company equipment or unapproved software or utilities, except as permitted by the Acceptable Use of Mobile Devices.

All internal users must receive appropriate communication and formal training to support the approved method of remote connection.

Remote Access Policy for External Users
Respond Capture ensures that all network connections to IT systems and information assets are protected from unauthorized access while permitting legitimate connections by authorized external users. Access requests must be reviewed by the asset owner, with records of granted access maintained and retained.

Remote access is only authorized via equipment verified as acceptable for facilitating remote connections, with a pre-installed connection configuration (e.g., VPN) approved by Respond Capture. External users must not connect to Respond Capture networks or IT systems using non-approved equipment or software.

All external user connections authorized for a valid business case must be controlled by a Respond Capture firewall, router, or equivalent network security device. External users are not allowed to use Respond Capture networks as a transit route to other destinations outside Respond Capture.

All external user connections must be protected by antivirus (AV) software as detailed in the Acceptable Use Policy. The AV software should be identical to that authorized for use by Respond Capture or, if different, must be reviewed and accepted by Respond Capture before the external connection is authorized.

Termination of Remote Access Connectivity
When an employee, contractor, or third-party user is terminated, all remote access must be immediately revoked by the Information Security Manager and/or Asset Manager upon receiving an approved Access Control Form requesting revocation. The Asset Manager must regularly review authorized access to assets and promptly remove any internal user who no longer has a valid business need to access the asset.

Upon contract termination with an external organization (including clients, contractors, and suppliers), all remote access must be immediately revoked by the Information Security Manager and/or Asset Manager upon receiving an approved Access Control Form requesting revocation. The Asset Manager must regularly review authorized access to assets and immediately remove any external user who no longer has a valid business need to access the asset.

Responsibilities
The respective Asset Owner is responsible for reviewing, authorizing (or denying), and managing all access to their assets. They must conduct regular reviews to ensure all access permissions remain valid for legitimate business reasons.

The Information Security Manager must escalate any information security incidents arising from access control breaches or failures.

All employees, contractors, third-party users, and external users of Respond Capture’s information systems must comply with this Access Control Policy at all times. Any failure to adhere to this policy will result in disciplinary action.

All employees must request all Access grants/revocations via the Access Control Form.

Change Management Policy (RC.7.1.24)

Objectives
This Change Management Policy is designed to ensure that any modifications to application code and related systems are controlled through appropriate measures. The policy aims to:

Minimize the risk of unintended consequences, such as defects or other negative impacts, through thorough review.
Enhance the awareness of changes across relevant teams.
Maintain a record of changes made to systems and repositories within its scope, whenever possible.

Scope
This policy applies to:

Changes to application code for Respond Capture ATS and all related sub-services. Specifically, any modifications to projects within the Respond Capture GitHub repository.
Modifications to the “Infrastructure as Code” definitions used for Amazon Web Services (AWS). This includes changes to the GitHub repository “respond-terraform” and the AWS CodeCommit repositories “respond-infrastructure” and “eu-respond-infrastructure,” which control system-level infrastructure resources in AWS.
Alterations to underlying information assets that support Respond Capture’s product offerings. This includes any changes to supporting services such as AWS, Pingdom, SolarWinds, or any other service listed on the third-party vendor registry relevant to these offerings.
Modifications to any business process affecting Information Security.
Changes to any documents impacting Information Security.
Organizational changes at Respond Capture that affect Information Security.

Responsibilities
The following roles are defined:

Administrator: A Respond Capture employee with administrative authority over a relevant system. Refer to the third-party vendor registry for a list of administrators for each system.
Engineer: A Respond Capture employee whose primary responsibility is to make changes to relevant systems.
Team Members: Architects and Engineers who are part of a specific team at Respond Capture, such as the infrastructure team (informally known as “Respond Infrastructure”).

Implementation

Application Code Changes
GitHub repositories containing application code, as outlined in Scope Item 1, must utilize GitHub’s “Branch Protection” feature to designate the repository’s base branch, and any other branches intended for release to end users, as protected. These protected branches prevent direct, unreviewed modifications by engineers.

As a result, any changes to protected branches must be submitted for review via GitHub’s “Pull Request” system. Each pull request must be approved by another engineer before it can be merged into a protected branch.

When reviewing code, engineers should evaluate:

The scope and impact of the change, ensuring it is clearly and accurately communicated.
Potential unexpected or unintended side effects of the change.
Any security implications of the change, in line with the Secure Engineering Principles.

In emergencies, a repository administrator may bypass the usual pull request review process on a case-by-case basis. Such cases must be reported to the Information Security Manager for further review.

Infrastructure as Code Changes
Repositories in GitHub and CodeCommit that contain “Infrastructure as Code,” as described in Scope Item 2, must also have one or more protected branches to prevent unauthorized changes.

Changes to these repositories must be submitted for review through the repository’s “Pull Request” system and reviewed by at least one other Team Member before being merged into a protected branch.

To expedite changes, a Cloud Architect may bypass the review process and deploy changes in an unprotected, submitted-for-review branch.

Infrastructure as Code changes may be deployed using the unprotected, submitted-for-review branch if any of the following conditions are met:

The environment is intended for internal use at Respond Capture.
The environment is being prepared for customer use, but access has not yet been granted to a customer.
The change is authored by a Cloud Architect.

Otherwise, the change must be reviewed, approved by another Cloud Architect, and then merged into the relevant protected branch for deployment.

For clarity, the following situations require review before deployment:

Any changes to an active customer environment.

Any changes that bypass the review process before deployment must eventually be reviewed and merged into the relevant protected branch of the repository. This review, even if cursory, ensures change awareness and provides a record of the change.

Changes to Respond Capture ATS environment configurations for production systems should typically be driven by a specific customer (internal or external) or a customer support request.

Other System Changes
Application and infrastructure code, covered in Scope Items 1 and 2, account for the majority of changes critical to the operation of Respond Capture systems.

Scope Item 3 is broader, covering both manual changes to systems typically controlled by “Infrastructure as Code” definitions (e.g., AWS changes) and modifications to supporting systems like third-party status pages, monitoring systems, etc.

Generally, Respond Capture strives to define infrastructure and applications in code whenever practical, guided by the longevity and impact of systems and changes. However, for some systems, particularly third-party systems, manual setup or changes are more realistic.

In these cases, covered by Scope Item 3, the following guidelines apply:

If there is a reasonable chance that a change may directly affect customer or production systems or data, the change should be supervised by at least one other Respond Capture employee. This supervising employee should have the knowledge and context to understand and evaluate the change, or they should refuse to sign off without first acquiring the necessary knowledge and context. Supervision can take the form of observing the change, viewing a screen share, discussing the change through instant messaging, or approving a pull request before deployment, depending on the situation.

When in doubt, employees should err on the side of having another person review and sign off on their changes.

Cryptographic Control Policy (RC.8.13.24)

Objectives
All systems that require authentication must use strong passwords in accordance with the Password Management Policy. Systems utilizing cryptography should employ industry-standard secure algorithms as outlined in this policy. Where applicable, Respond Capture will adhere to all legislative or regulatory mandates regarding cryptographic controls by conducting Threat and Risk Assessments followed by the appropriate Change Management Policy procedures. Data, whether stored or transmitted, must be encrypted both at rest and in transit.

Scope
Respond Capture’s Cryptographic Control Policy applies to the following:

All information assets (data) either owned by Respond Capture or entrusted to Respond Capture by a client under an agreement that specifically outlines Respond Capture’s data responsibility.
Information assets held, processed, or stored at Amazon Web Service (AWS) facilities under accounts owned by Respond Capture used to support Respond Capture's product offerings.

Policy

General Requirements
Do not implement custom encryption methods. Always use industry-standard encryption techniques known to be secure.

HTTPS
Scoped assets with HTTPS servers must be configured as follows:

TLS protocols used must be from the Acceptable SSL list provided below.
TLS cipher suites available must be from the acceptable cipher suites list provided below.
When possible, the server should prefer to negotiate using the preferred protocol and cipher suites from the lists below.

Acceptable SSL/TLS Protocols

TLSv1.2
TLSv1.3

Preferred SSL/TLS Protocol

TLSv1.2

Acceptable Cipher Suites

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-CBC-SHA
ECDHE-ECDSA-AES256-CBC-SHA
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA

Preferred Cipher Suites

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384

Encryption at Rest
All data encryption at rest must use AES-128 encryption or stronger. Encryption keys for data at rest will be maintained within the Amazon Web Services Key Management System.

Application-Level Cryptography
Applications developed by Respond Capture will use the following cryptographic methods when handling sensitive data:

Bcrypt or stronger for storing passwords in a database.
MD5 or stronger for creating one-way hashes to anonymize data.
AES-128 or stronger for encrypting data with an appropriate mode of operation.

Key Rotation

TLS keys (used for HTTPS) for certificates issued through Amazon Certificate Manager by Respond Capture will be rotated annually.
TLS keys for certificates issued by a third-party customer will be rotated at least every three years.
Keys used for encryption at rest in Amazon Web Services Key Management System will be rotated every year (for Respond Capture-managed keys, also known as “CMKs”) or every three years (for Amazon-managed keys).
Keys used for application-level cryptography will be rotated at least every three years.

Responsibilities

The Information Security Manager is responsible for ensuring that the cryptographic controls outlined in this document provide adequate protection for the company’s assets.
Asset owners are responsible for ensuring that their information assets comply with the cryptographic controls listed in this document.

Incident Management Policy (RC.8.21.24)

Objectives

Restore normal service operations as quickly as possible.
Minimize the negative impact on business operations.
Ensure that agreed-upon service quality levels are maintained.
Use standardized methods and procedures for efficient and prompt response, analysis, documentation, ongoing management, and reporting of incidents.
Enhance visibility and communication of incidents to business and IT support staff.
Improve the business's perception of IT by employing a professional approach in swiftly resolving and communicating incidents.
Align Incident Management activities and priorities with those of the business.
Maintain user satisfaction with the quality of IT services.

Scope

This Respond Capture Incident Management Policy governs and guides decisions and actions taken during service operation failures that cause, or may cause, interruptions or reductions in service quality.

The scope of this policy applies to all incidents reported by Respond Capture employees, vendors, and third-party contract personnel (consultants/contractors) concerning IT infrastructure, hardware, software, system components, virtual components, cloud components, networks, services, documents, and processes.

Information security incidents reported to Respond Capture by a client or any individual/entity not covered above should be documented using the IRT Incident Report Form by the employee receiving the notification.

Incidents compromising business continuity are addressed in the Respond Capture Business Continuity Management Plan.

Policy

Incident Detection
Incident detection can be the most challenging phase of the incident response process. In many cases, it is evident that a security incident has occurred—for example, when a website is defaced or when a user account is accessed while the actual user is on vacation. However, in other instances, determining if a security incident has occurred may be less straightforward. Here are some ways to identify a potential security incident:

Users: Users, including system administrators, are often the first to notice an issue with an information resource. For example, a user might report that their login no longer works or that the system showed a login while they were on vacation. System administrators may notice a compromised resource if the system slows down, if there are more users logged in than usual, or if they detect a new or unauthorized process running.
System Alerts or IDS/IPS Alerts: Respond Capture has auditing enabled for all information resources processing sensitive information, as well as strategically placed network and host-based intrusion detection systems (IDS). Ideally, audit logs or IDS would indicate an attempted or successful intrusion.

As a general rule, if you suspect something, report it to your immediate manager.

Incident Reporting
All Respond Capture employees, contractors, and vendors are responsible for immediately reporting security violations, incidents, or unusual or suspicious system activity using the IRT Incident Report Form. Incident reports should then be sent to the Respond Capture Information Security Manager to determine the appropriate response actions to investigate and resolve the incident. If necessary, the Information Security Manager will activate the Respond Capture Incident Response Team (IRT) and the LTG Help Desk. All incident data is captured on the IRT Incident Report Form. The CEO is the only person authorized to contact law enforcement.

Incident Response
Upon notification of a security incident via the IRT Incident Report Form, the Information Security Manager will determine the appropriate course of action and, if necessary, invoke the Respond Capture Incident Response Team (IRT) and the LTG Help Desk. If engaged, the IRT is responsible for managing the resolution process, including user or system notification, escalation actions, follow-up actions, and post-incident reporting.

Incident Recovery
Once the incident is deemed "contained" or "closed," Respond Capture personnel may be required to recover the systems involved. The primary goal of the recovery process is to restore the system to a more secure state than before the incident. This involves not only restoring data and applications as necessary but also ensuring that the original vulnerability has been remediated.

Additionally, as part of the recovery process, all system and user passwords should be changed following an incident, if applicable.

Secure Evidence
Much of the evidence on information resources is volatile and may be deleted or overwritten during normal system operations. At a minimum, all system logs must be immediately copied to offline storage to preserve them and prevent deletion through normal operations or deliberate actions by the intruder. If feasible, a complete backup of the compromised system should be made and secured. This preserves the system's condition at the time of the compromise and prevents the intruder from erasing files.

The Information Security Manager should copy log files and create a backup of the compromised system if possible. Users should not access the affected system unless they have the expertise to perform these functions, as they risk damaging or deleting evidence. All operational activities conducted by the Information Security Manager or Incident Response Team must be fully documented via the IRT Incident Report Form for use in legal proceedings, if necessary.

Computer Forensics
Computer forensics involves prioritizing, identifying potential evidence, and preserving and analyzing information related to the security incident. As a first responder, the Respond Capture Incident Response Team (IRT) leader will determine when computer forensics should be performed on a compromised information resource. Respond Capture may need to employ a third-party expert to gather, preserve, and analyze the evidence. Improper handling of evidence can jeopardize any legal recourse for Respond Capture. Forensic principles for evidence handling must be followed, including but not limited to:

Rule of Best Evidence: Every effort should be made to extract information as close to its original form as possible. Backups should be made, and log files exported to non-writable media as soon as possible.
Chain of Evidence: Evidence must be fully accounted for from discovery to disposition.
Contamination: Handling procedures should be designed to avoid any risk of contamination, alteration, or appearance of potential contamination.
Investigation and Analysis: This step aims to determine the cause, impact, and steps needed to resolve the issue. The process is designed to implement both immediate and future prevention strategies.

Responsibilities

The IRT Incident Report Form is the first point of contact for all Respond Capture personnel. This form helps identify potential security incidents and initiates appropriate procedural actions. It notifies the Respond Capture Information Security Manager of any information security incidents. If warranted, the Information Security Manager notifies the Respond Capture Incident Response Team and the LTG Help Desk.
The Respond Capture Incident Response Team (IRT) has clearly defined roles and responsibilities for escalating and resolving computer security incidents. The Information Security Manager, as the leader of the Incident Response Team, plays a crucial role and periodically reviews the incident response procedures to ensure they remain up-to-date. The IRT, when employed, is responsible for managing the resolution process, including user or system notification, escalation actions, follow-up actions, and post-incident reporting.
All employees are encouraged and required to report any observed or suspected security weaknesses in systems or services, even if not classified as an incident.

Information Backup Policy (RC.8.11.24)

Objectives
Business information and services are critical components of any organization and must be safeguarded. Simply saving data is insufficient; performing backups of all application-critical information within Respond Capture is essential to prevent business downtime or data and service loss. Without adequate backups, failures due to computer malfunctions, human errors, or natural disasters could lead to irreversible interruptions.

The objective of this policy is to protect Respond Capture’s information assets, prevent data loss due to accidental deletion or corruption, and ensure the timely restoration of information and business processes in the event of a system failure. This Information Backup Policy aims to protect both the company and individual users.

Backing up Respond Capture’s data files and ensuring the ability to recover such data is a top priority. Management is responsible for ensuring that backup frequency and recovery procedures align with the professional standards and product goals of Respond Capture and the Applicant Tracking System.

Scope
The Respond Capture Information Backup Policy applies to all information assets, information systems, and other resources provided by Respond Capture to support the Applicant Tracking System.

Policy

General Requirements
Backups of Respond Capture servers and data must be retained to ensure that server operating systems and applications are fully recoverable with minimal data or service level agreement (SLA) loss. This may be achieved through a combination of snapshots, copies, incremental backups, differential backups, transaction logs, replication, or other techniques.

Respond Capture employs two types of storage: object and block, for all storage needs. Generally, object storage is managed using Amazon S3, and block storage is handled using Amazon Elastic Block Store (EBS) volumes. These services must employ appropriate scalability, data availability, security, encryption, lifecycle, and performance properties to meet or exceed Respond Capture’s contractual service levels. Exceptions to this policy must be approved by the Technology Director via a completed Threat and Risk Management Form following proper change management procedures.

Information system owners must ensure that adequate backup, system recovery, and testing procedures are in place to recover from service level losses in a safe and timely manner. Application-critical object storage buckets, identified by cross-region replication tags, must employ cross-region replication to ensure rapid recovery from service loss in their primary S3 operations region. These buckets must also be configured for daily inventory checks to ensure a physical inventory report is available in the Respond Capture inventory and analytics storage. Application-critical object storage must undergo quarterly audits, using random statistical sampling, to verify existing inventory at the replication destination. Application-critical block storage volumes must be backed up nightly. These backups must be tested daily by migrating the previous night's production backup into the development environment to ensure safe and timely recovery.

Management must ensure safeguards are in place to protect data integrity during recovery and restoration, especially when restoring data may overwrite more recent data. Application-critical object storage must employ versioning and replication as safeguards, while block storage must use encrypted backups and snapshots to ensure data integrity.

Storage media and services used for archiving information must be suitable for the expected data longevity. The format in which data is stored must be carefully considered, particularly when proprietary formats are involved. Amazon S3 object storage and Elastic Block Store services must be used to meet or exceed data durability and availability service levels in support of Respond Capture’s contractual obligations. Object storage is currently retained indefinitely due to the relatively low cost of storage. Block storage retention is set at 30 days to align with Respond Capture’s contractual obligations per ISMS Clause 4.

Business information should not be stored on laptops or portable computers. As a remote workforce, all business information should be stored in the cloud, either in a company cloud drive or a company-owned personal cloud drive.

Definitions

Backup: The process of creating additional copies of information stored on different servers and computers in case the original data is lost or damaged.
Restore: The process of returning to a former condition using a backup.
Cross-Region Replication: The process by which an object created or updated in one region, such as us-east-1, is immediately replicated to another region for backup.

Responsibilities
The Technology Director is responsible for ensuring that this Information Backup Policy remains current and aligned with Respond Capture’s business activities and security objectives.
All Respond Capture employees, contractors, and third-party vendors are responsible for complying with all information backup requirements detailed within the scope of this policy.

Information Classification & Handling Policy (RC.8.1.1.24)

Information Classifications
A method for classifying information resources is essential to determine appropriate controls based on the relative business value or sensitivity of those assets. Information classification helps establish how information will be handled and protected during storage, transmission, use, and when shared or disposed of, both in print and electronically, based on the sensitivity of the data.

Respond Capture provides and maintains its information technology resources primarily for conducting business operations. These systems must be used professionally, responsibly, ethically, and legally at all times. All information stored, transmitted, used, shared, or disposed of is the property of Respond Capture and not the individual user. Information classification provides a common understanding of the level of protection required for specific information resources. This policy also extends to third-party information retained or handled during Respond Capture's business operations. Improper handling of information can result in serious financial loss, compromise of employee or business partner data, or loss of public trust.

By default, all unmarked or unclassified information should be considered “Sensitive” until the owner of the information determines further classification.

Open
Information classified as OPEN should have no serious or detrimental effect on the organization if disclosed or lost accidentally. Before using this classification, consider whether you are comfortable with all personnel, clients, and competitors having access to this information.

Examples of information that may be classified as OPEN include, but are not limited to, press releases, white papers, research documents, certain policies and processes, and other information openly shared with all employees, clients, and competitors.

Information in this category is unlikely to require encryption due to its nature and, therefore, will not be subject to the Respond Capture Cryptographic Control Policy.

Sensitive
Information classified as SENSITIVE should be restricted to personnel within the organization and trusted external individuals or organizations. Typically, external parties should be under a contractual Non-Disclosure Agreement (NDA) to protect this information and understand how it must be protected.

Examples of information classified as SENSITIVE include, but are not limited to, service reports, performance data, certain contractual agreements, most policies and processes, company strategies and plans, details of forthcoming changes to products and services, and other information that should not be shared with the entire client base or a competitor.

Information in this category may require encryption, depending on the Information Classification and Handling Policy, and therefore may be subject to the Respond Capture Cryptographic Control Policy.

Confidential
Information classified as CONFIDENTIAL should be restricted to personnel within the organization or the owners of the information. Personnel will need specific training and contractual clauses in their employment terms to enforce non-disclosure of material outside the organization.

Examples of information classified as CONFIDENTIAL include, but are not limited to, financial budgets and reports, and other information not readily shared with clients, suppliers, or others outside the organization.

Information in this category requires encryption and is therefore subject to the Respond Capture Cryptographic Control Policy.

Secret
Information classified as SECRET should be restricted to personnel within the organization or the owners of the information. Any external recipient of secret information should be under a contractual NDA to protect this information and understand how it must be safeguarded. Personnel will need specific training and contractual clauses in their employment terms to enforce non-disclosure of material outside the contracted organizations.

Examples of information classified as SECRET include remuneration, payroll and benefits details, user personally identifiable information (PII) and records in Software as a Service (SaaS) and managed hosting products, and other information not commonly known among the workforce.

Information in this category requires encryption and is therefore subject to the Respond Capture Cryptographic Control Policy.

Principles of Data Access
Access should be granted only to individuals with a legitimate and justified need for information access. Even if an individual holds an appropriate security clearance, clearance alone does not grant automatic access to information of a corresponding classification. The information asset owner must grant and remove access based on validated requirements.

New employees will initially have the most basic access to information and IT facilities, which can be modified based on their progression or increased responsibilities. When an employee changes position or department, their access rights will be reviewed and adjusted accordingly. Employees leaving the company will have all access rights revoked immediately.

Further details can be found in the Access Control Policy.

Information Handling

Handling Method

Open

Sensitive

Confidential

Secret

Photocopying

No restrictions

With care, collect promptly

Transmission by Fax

Ensure fax confirmation is obtained

Contact recipient to confirm receipt

Prohibited

Sending by Post or Courier

No restrictions

Single envelope, marked with recipient’s details

Signed-for service only. Double envelope, inner one marked appropriately.

Signed-for service only. Double envelope, inner one marked. Check for signs of tampering.

Transmitting by Email

No restrictions

NDA for external: consider encryption

NDA for external: preference for encryption

NDA for external: compulsory encryption

Transmitting Over the Internet

No restrictions

NDA for external: consider encryption

NDA for external: preference for encryption

NDA for external: compulsory encryption

Access on Mobile Devices in Public Places

Care to avoid possible eavesdropping

Not recommended, avoid if possible

Prohibited

Information when Traveling

Care should be taken

Care should be taken—documents and equipment not to be left unattended

Extra care should be taken. Carry on person; only leave data in properly secured storage.

Printing of Information

No restrictions

With care, only to printer in immediate vicinity; collect or destroy promptly post-use.

Storage of Information in Printed Form

No restrictions

Dependent on specific content

Locked drawer, filing cabinet, or safe

Disposal of Information in Printed Form

Recycling

Shredding

Shredding (cross-cut)

Reporting Loss, Theft, or Compromise

Not required

Raise an Information Security Incident

Disposal, Recycling, and Reuse of Magnetic or Flash Storage

Delete all data

Use a DOE-compliant 3-pass (or higher) deletion method in MacOS Disk Utility before disposal, recycling, or reuse.

Data Storage and Classification
All critical business information and software on Respond Capture information resources must be periodically backed up. Business/Asset owners are responsible for identifying backup schedules and determining the scope of information to be backed up. Users are responsible for backing up any critical files.

Retaining outdated or incorrect information can cause business complications and confusion and places Respond Capture at risk of liabilities if the information is inadvertently disclosed. Therefore, Respond Capture employees should not retain data that is no longer relevant to business operations unless required for other reasons, such as financial audits or legal obligations.

For additional guidance on data storage, refer to the Respond Capture Information Backup Policy.

‍

Malware Policy (A.12.2.1)

Objectives

To ensure Respond Capture's information assets (data) and software are protected against intrusion, infection, damage, or compromise caused by malware, including viruses, Trojans, malicious scripts, and other malicious software.
To ensure that appropriate anti-virus software is approved for use and applied to all hardware assets (within the scope of this policy) to protect information and software assets.

Scope
Respond Capture’s Malware Policy applies to the following:

All information assets (data) either owned by Respond Capture or entrusted to Respond Capture by a client under an agreement that specifically details Respond Capture’s data responsibility, including but not limited to:some text
- Information assets held, processed, or stored at Amazon Web Service facilities under accounts owned by Respond Capture used to facilitate Respond Capture product offerings.
- Any desktop or laptop used to access the aforementioned information assets.
- The hardware and software assets owned by third parties that have been authorized by Respond Capture to access Respond Capture information assets.
All employees, contractors, and third-party users who have a legitimate requirement to access, process, store, or transmit Respond Capture information assets.

Policy

General Anti-Virus
Respond Capture shall use Apple Gatekeeper as its primary product for protecting company laptops against viruses, Trojans, and other malware. Gatekeeper is installed by default with the Mac OS on company laptops. This protection shall:

Operate in real-time on all desktops, laptops, and other devices capable of supporting its operation.
Be configured to receive, update, and act upon updates to virus/threat library definitions.
Be configured to only allow applications from the Apple App Store or identified developers.

All personnel covered by this Malware Policy shall:

Not perform any action that prevents the anti-virus software from operating in real-time.
Not perform any action that prevents the automatic update of virus definitions.
Promptly report any suspected or actual breach in accordance with the Virus Incident Escalation process detailed below.
Maintain awareness of the threats and characteristics of viruses and other malware.

Email Anti-Virus
Respond Capture shall use Google Workspace’s Gmail service for email, which enhances protection against viruses and other malware by implementing anti-spam controls to detect, isolate, and delete unsolicited emails that may be used to deliver viruses or other malware. Gmail rejects any message containing a detected virus and notifies the sender that the email was rejected due to the virus attachment. Gmail prevents the download of any attachment detected as containing a virus.

Virus Incident Escalation
Any user who notices activity or messages indicating that a computer system or data has been affected or compromised by a virus or other malware shall:

Immediately isolate the suspected computer system by disconnecting and removing all wired or wireless network connections if applicable, preventing any further use of the system, and identifying all backup media and any other peripheral storage devices connected to the suspected computer system. If it is suspected that the incident is aggressive and may have already spread within the Respond Capture network, the entire network shall be promptly disabled pending full virus scanning and remedial action.
Immediately report the incident as an information security incident in accordance with the Incident Management Policy.

NOTE: The use of the information security incident form should not be undertaken from the suspected computer system, as this may cause further distribution of the virus or malware. The incident should be reported verbally if an uncompromised computer system is not available.

Upon receipt of the information security incident notification, appropriate resources shall be promptly allocated to investigate, diagnose, and disinfect the suspected computer system, along with any related backup media and peripheral storage devices. The same action shall be taken with any connected computer systems suspected of infection.

Following the successful resolution of the information security incident, Respond Capture shall examine the circumstances to understand how it occurred. This process shall involve implementing corrective actions, which may include upgrading anti-virus software or its configuration. If user error is identified, appropriate anti-virus and malware training shall be scheduled in accordance with the Information Security Training Policy.

Responsibilities

Hardware and Software Asset Owners are responsible for ensuring, typically through risk assessments, that their assets are provided with appropriate protection against infection by viruses and other malware.
Information Asset Owners are responsible for ensuring, typically through a risk assessment, that their information is protected against breaches of confidentiality, integrity, or availability caused by viruses and other malware.
The Information Security Manager shall coordinate and manage any information security incidents resulting from suspected or actual virus or malware activity. The manager shall also coordinate post-incident analysis and arrange for any corrective actions identified.
All employees, contractors, third-party users, and external users of Respond Capture’s information systems (as defined within the scope of this policy) must comply with the requirements of this Malware Policy. Any incident of virus or malware infection or compromise attributed to an individual not adhering to this Policy shall result in disciplinary action.

Password Management Policy (RC.8.2.1.24)

Objectives

Ensure that all systems requiring authentication use strong passwords as part of the authentication process.
Ensure that all systems requiring authentication have a process in place to replace lost or stolen credentials.

Scope
Respond Capture’s Password Management Policy includes the following:

Information Assets
All information assets (data) either owned by Respond Capture or entrusted to Respond Capture by a client under an agreement that specifically outlines Respond Capture’s data responsibility, including but not limited to:

Information assets held, processed, or stored at Amazon Web Service facilities under accounts owned by Respond Capture used to facilitate Respond Capture product offerings.

Hardware: Network infrastructure, laptop computers, desktop computers, storage infrastructure, and mobile devices.
Software: Operating systems, commercially available software applications, and software applications developed internally by Respond Capture.
Data: Information encrypted with a password-protected key.

Policy

User Password Management
This section outlines the requirements for Respond Capture employees who are creating and managing passwords.

When using password-based authentication, keep the following goals in mind:

It should be difficult for anyone to guess your password, even if they know you.
It should be difficult for an automated program to guess your password through “brute force.”
Your passwords must be kept secret: sharing passwords reduces the security of an account.

With these goals in mind, Respond Capture recommends, when possible, that all passwords be randomly generated by and stored in 1Password, Respond Capture’s password management tool of choice. Each password must be unique to the account. By randomly generating passwords for each site, it becomes effectively impossible for anyone to guess the password, provided it meets certain requirements.

For all passwords, Respond Capture requires the following:

Only share passwords when absolutely necessary. If possible, unique accounts should be used instead of sharing credentials. Passwords may only be shared through 1Password Vaults.
Passwords must be changed if there is a reasonable suspicion that a system or account has been compromised.
Passwords must be stored securely. At a minimum, passwords must be encrypted in storage and should not be written down in plain view. Respond Capture provides 1Password access to all employees and recommends storing passwords within it.

For randomly-generated passwords specifically, generated and stored via 1Password, the following additional requirements apply:

Passwords must be unique and never reused.
Passwords must be at least 20 characters long, or the maximum character count allowed by the system if less than 20 characters.
Passwords should use a mix of lowercase, uppercase, numbers, and special characters when allowed by the system. Since these passwords are stored in 1Password, they do not need to be memorable.

For passwords created by the user and memorized instead of being kept in a password manager, the following additional requirements apply:

Passwords must be unique and never reused.
Passwords should be changed at least annually. When changing passwords, do not use the original password as the basis for the new password.
Passwords must not be a single dictionary word or proper noun.
Passwords must be at least 10 characters long, or the maximum character count allowed by the system if less than 10 characters. Keep in mind that shorter passwords are easier to guess.
Passwords should be memorable but difficult for others to guess. Consider:some text
- Using a unique statement or a collection of 4 or more words separated by a non-alphanumeric character.
- Using 1Password’s password strength estimator to ensure passwords are of high quality.
- Incorporating a mix of uppercase, lowercase, numbers, and special characters to increase resistance against both manual and automated guessing.

System Password Implementation
This section outlines the requirements for password-based authentication implementation by developers at Respond Capture.

The following requirements apply to all software developed and maintained by Respond Capture:

Passwords used for user authentication must use a password hashing function to store a “fingerprint” of a user password for later verification instead of storing the password directly. Respond Capture uses Bcrypt as its password hashing function for the software it develops.
When a system requires access to the password itself, such as for interacting with another system, the password must be encrypted in storage.
Passwords must be encrypted in transit.
If there is a reasonable suspicion that a system has been compromised, all passwords must be reset.
When applicable, password reset links must have an expiration date.
When applicable, prefer non-memorized means of authentication, such as key-based authentication, over password-based authentication.

Lost/Stolen Credentials
For any Respond Capture internal or external system requiring authentication, follow this process if login credentials are lost, stolen, misplaced, or forgotten:

Notify your immediate manager or the Technology Director if your manager is unavailable.
Create an Information Security Incident Report.

Responsibilities

All employees are responsible for maintaining strong passwords and ensuring they are protected.
Architects and engineers are responsible for ensuring that systems adhere to the system password implementation requirements.

Physical Security Policy (RC.1.8.1.24)

Objectives
The objective of this policy is to document Respond Capture’s physical security controls concerning a fully remote workforce.

Scope
This physical security policy applies to the information processing facilities used to deliver Respond Capture's product offerings. As a fully remote workforce with no central office, this policy exclusively covers third-party data centers.

Policy

Third-Party Information Storage and Processing
All customer information storage and processing are conducted in third-party facilities. For the scoped services, Respond Capture uses Amazon Web Services (AWS) as its primary infrastructure provider. Respond Capture relies on AWS to maintain physical controls for the in-scope systems responsible for storing and processing customer data. AWS's controls are detailed in Amazon’s Data Center Controls document.

Other third-party providers may also be used in providing the scoped services, as outlined in our Vendor Security Policy. In these cases, Respond Capture expects these suppliers to maintain appropriate physical security controls.

Secure Engineering Principles (RC.1.8.1.24)

Objectives
Respond Capture implements several information systems. To ensure these systems are secure, the principles outlined in this document must be followed during the design, implementation, maintenance, operation, and improvement of our information systems.

Scope
Respond Capture’s Secure Engineering Principles apply to all product offerings from Respond Capture.

Policy

Secure Engineering Principles

Ensure information is secure when processing, transmitting, and storing data.
When implementing information systems, it is essential to ensure that the data within the system remains secure throughout its entire lifecycle. Whether data is being processed, transmitted, or stored, its security must be maintained at all times.
Remember, the information belongs to the customer.
Always remember that the information in the systems belongs to Respond Capture's customers. Respond Capture has a duty to protect this information and is compensated for doing so. When evaluating the security of information, Respond Capture’s standards should always meet or exceed the customer’s requirements. If the customer’s requirements cannot be met, Respond Capture will either make necessary improvements, reach an agreement with the customer on the adequacy of Respond Capture’s standards, or inform the customer that the incompatibility of information systems and their requirements prevents Respond Capture from accepting their business.
Evaluate all changes and new implementations for the most critical security risks.
Given that all of Respond Capture’s products are web applications or components of web applications, it is crucial to ensure that any new or modified functionality does not introduce one of the OWASP Top 10 Most Critical Web Application Security Risks. Following this principle is one of the simplest ways to ensure compliance with the other principles in this document.
Establish baselines for a minimal level of security.
When evaluating information security, consider not only the most secure methods but also the minimum acceptable level of security. For example, when encrypting data for transit, the upper bound for a key size may be limited by practical considerations such as transmission size and processing time, while the lower bound is determined by how long the data must be protected from brute-force attacks. Establishing a baseline is as important as determining the most secure implementation because it helps recognize when implementations are "not secure enough" or "more than secure enough."
Produce evidence of security throughout the lifecycle of an information system.
Throughout the lifecycle of an information system, evidence of security should be produced. This evidence serves two primary purposes: it aids in creating accountability and auditability and provides Respond Capture with tangible proof of engineering secure information systems. For example, when addressing a security concern in a code change, ensure a Trello ticket tagged with “security” exists and is referenced in the change.
Perform retrospective evaluation if vulnerabilities are discovered.
If a security vulnerability is discovered in a product, a retrospective evaluation must be conducted as part of the associated security incident. Specifically:some text
- Engineers will review other code and systems maintained by Respond Capture to ensure they do not have the same vulnerability.
- Respond Capture will evaluate how the vulnerability was introduced, whether through poor code review or insufficient vulnerability scans.
- A treatment plan will be created based on these findings, containing specific improvements to mitigate or prevent the introduction of similar vulnerabilities in the future.

Responsibilities

The Information Security Manager is responsible for ensuring that the Secure Engineering Principles remain current and aligned with Respond Capture’s business activities and security objectives, as well as ensuring compliance with products covered by the Scope of this Policy.
Asset owners and engineers responsible for developing information systems within the Scope of this Policy must ensure that the Secure Engineering Principles are applied in the development of their respective systems.

System Hardening Guidelines (RC.3.8.1.24)

Objectives
This document outlines the general principles that Respond Capture uses to harden its systems against malicious attacks. It provides broad guidance for system implementers with specific recommendations where appropriate.

Scope
This policy covers all public-facing systems and critical internal systems used to facilitate product offerings from Respond Capture.

Policy

General
Amazon Web Services (AWS) is the only approved hosting provider for Respond Capture products within the scope of this policy. All sensitive customer data must remain within AWS data centers. AWS and Respond Capture operate under a Shared Responsibility Model of security, as explained by AWS in their online documentation. In summary, AWS is responsible for the security "of the cloud" (i.e., the services it provides), while Respond Capture is responsible for the security "in the cloud" (i.e., selecting and configuring AWS services, servers, etc.).

Systems should be defined using "Infrastructure as Code" (IaC) tooling where practical. Specifically, AWS configurations should be defined in CloudFormation (legacy). Server configurations should be defined in Ansible, BASH scripts, or Systems Manager State Manager. When appropriate, changes to this code should undergo peer review as per the change management policy before being applied.

Alerts from security monitoring services such as Inspector, Shield, WAF, GuardDuty, or Config should be surfaced in an employee-visible manner. Depending on the severity, alerts may be sent via email, IM (Slack), or paging (SMS via SNS).

AWS
AWS access must be configured to require multi-factor authentication (MFA) for both the root account and any individual AWS IAM users.

Every AWS account must be joined into the LTG Enterprise AWS Organization. Each account should have IAM roles that allow Enterprise Support and Billing Support to have limited read-only access for support purposes. Read-only access should be restricted to non-sensitive data. Specifically, Support must not have the IAM permission s3

except for buckets specific to Support.

The following AWS services must be enabled in all relevant regions:

CloudTrail: AWS's audit logging service.
GuardDuty: Performs network intrusion detection and anomaly alerting for CloudTrail logs.
Config: Checks AWS configurations against known baselines.
Security Hub: With the CIS Benchmark suite enabled, allows measurement of CIS benchmark compliance.

CloudTrail logs must be retained for at least two years, ideally in multiple regions.

Networking
Since customer data remains within AWS, networking guidelines are specific to AWS.

The security of physical networking equipment is managed by AWS per the Shared Responsibility principle.

Changes to networking configuration are recorded by AWS CloudTrail. These changes are archived for later analysis if needed, in addition to being analyzed by GuardDuty and Inspector for suspicious activity.

Where allowed by AWS, systems should reside in an AWS Virtual Private Cloud (VPC), which is a software-defined network with an associated RFC 1918 private IP address block. Each VPC's private address block is divided into subnets, which can be either public (with direct internet access) or private (without direct internet access, or with internet access only through a Network Address Translation (NAT) gateway).

Systems not intended for direct internet access should be placed in private subnets whenever possible. These systems will not have public IP addresses, and communication with them directly from the internet is impossible without an initial outbound connection (tracked by the NAT gateway). In addition to firewalls, this provides an effective layer of security.

AWS provides firewalls for systems through its "security group" feature, among other offerings. Every system in a VPC can be associated with multiple security groups, with the default state (having no associated security groups) being "DENY ALL." Each security group can open a port and protocol to a specific IP address range.

No firewall rules may accept all traffic from any port/protocol from a public IP address (i.e., the internet). Rules allowing traffic from public addresses must specify particular protocols and ports needed for a service to function and no more. Rules restricted to a VPC's internal IP address block, however, may open entire port ranges. Access to VPC internal networks must be facilitated through Respond Capture's VPN service.

If a firewall rule allows incoming traffic from 0.0.0.0/0 (i.e., no restriction on incoming IP addresses), it must restrict traffic to TCP port 80 (HTTP), TCP port 443 (HTTPS), or UDP port 1194 (OpenVPN). Only web services or VPN servers may be exposed to the public internet without restriction. Specifically, general public SSH access is banned by this policy.

SSH access should be restricted to the VPC's internal network, accessible via VPN. In rare cases, if necessary, firewall rules allowing SSH access from a specific public IP address, such as an employee's home network, may be temporarily added—for example, to allow initial configuration of a VPN server for later use. These rules should be labeled in a manner like "<name> Temp Home SSH" for easy identification.

Most servers should not be accessible directly from the internet. When possible, internet-facing traffic should be directed into AWS-managed services like CloudFront or load balancers, rather than exposing Respond Capture servers to the internet directly, even if those AWS-managed services subsequently communicate with Respond Capture-managed servers.

Network intrusion detection, including analysis of VPC flow logs and DNS requests, is performed by AWS GuardDuty.

Servers
All servers must be hosted in Amazon Web Services. In most cases, this means full VMs on Amazon EC2 instances. However, it is also acceptable to use AWS's other serverless managed offerings, such as Lambda.

Respond Capture's operating system of choice is the Ubuntu distribution of Linux, specifically any Long-Term Support (LTS) releases still receiving public maintenance patches from Canonical. Operating system versions must be upgraded at least three months before public maintenance patches are discontinued. Other operating systems may be used for internal testing but are prohibited from processing any sensitive data.

Systems should be configured to ship relevant log files to a central log service where possible. For EC2 servers, this includes the system journal, any application log files, and the operating system authentication log. For Lambda functions, the default AWS setup (CloudWatch Logs) is considered sufficient.

Operating Systems
For cases where Respond Capture manages the underlying operating system (OS), such as for in-scope EC2 instances (servers), the following policies apply:

The OS must have a baseline set of services configured, including:some text
- NTP: To ensure servers have the correct date and time configured.
- Inspector: For vulnerability management and intrusion detection.
Direct access to the root account on the system must be disabled, typically achieved by letting the normal EC2 startup process randomize the password. As a result, "sudo" is the only mechanism available to elevate normal users to root.
When possible, servers should be logically single-purpose.
SSH access for the root user must be disabled. SSH access for other users is allowed (provided it is not open to the public per the networking policy above), but other users must not use password-based authentication. Purely key- or certificate-based SSH authentication is recommended.
Unattended automatic upgrade services on critical production systems should be configured to avoid automatic restarts of the machine or its services, or the unattended upgrade daemon should be disabled. Automated restarts pose a threat to availability and must be managed more intelligently.
Systems must ship relevant or important log files to a central location for storage and analysis.
Any unnecessary OS services should be disabled. For example, if the server doesn’t need Apache httpd for its role, Apache httpd should be disabled or ideally not installed at all.
Server configurations should be written as code in Ansible and follow the documented Change Management Policy.

Responsibilities
System implementers are responsible for adhering to these guidelines. Operations staff may implement technical controls to verify or periodically check compliance with certain guidelines.

Vulnerability Management Policy (RC.81.1.24)

Objectives
The primary objective of this policy is to prevent the exploitation of technical vulnerabilities by ensuring that:

Information about technical vulnerabilities is obtained in a timely manner.
Respond Capture evaluates its exposure to vulnerabilities.
Appropriate measures are taken to address the risks associated with vulnerabilities.
Only approved personnel are allowed to install approved software.

Scope
This policy applies to Respond Capture’s:

Infrastructure resources within Amazon Web Services (AWS).
Product application code and resources used to support the following product offerings:some text
- Respond Capture ATS.

Policy

Software Installation
Only approved users are permitted to install software on scoped systems. The installation of software is governed by the Change Management Policy.

Penetration Testing
Respond Capture conducts weekly reverse reachability tests and annual third-party penetration tests to identify system-level vulnerabilities. These penetration tests produce reports of vulnerabilities, which are subsequently tracked and remediated according to a timeline based on the scope and severity of each item.

These penetration tests complement, but do not replace, other vulnerability monitoring strategies described below. They provide an effective third-party evaluation of Respond Capture's internal vulnerability management procedures. The results of these tests are used to improve internal processes.

Operating System
Operating system vulnerabilities refer to potential weaknesses in the Linux kernel, in the packages provided by a specific Linux distribution (e.g., Ubuntu or RHEL), or in the configuration of the operating system or its attendant services.

As outlined in the System Hardening Guidelines, each server has the AWS Inspector agent installed. Inspector maintains an inventory of all currently running servers and any vulnerabilities in their operating system packages as identified by the NIST National Vulnerability Database (NVD), categorized by their Common Vulnerability Scoring System (CVSS) score into high, medium, or low. Infrastructure staff uses Inspector's vulnerability monitoring as one source for identifying potential operating system vulnerabilities.

Infrastructure staff also monitors the security announcement mailing list for Respond Capture’s Linux distribution of choice, Ubuntu. Newly published operating system vulnerabilities, along with remediation instructions, are disseminated through these lists.

Once a potential operating system vulnerability is detected, operations staff evaluates the associated risks. If the vulnerability is determined to be legitimately exploitable, a patch or temporary mitigation will be rolled out within one week, typically sooner. This process may result in an Information Security Incident being raised.

Application

Source Code
In addition to weekly internal and annual external penetration tests for system-level vulnerabilities, developers evaluate changes made to application code as described in the Change Management Policy and Secure Engineering Principles to identify application-level vulnerabilities.

Dependencies
Before release, application dependencies are scanned for known vulnerabilities in the NIST NVD by looking up each dependency using its Common Platform Enumeration (CPE) identifier.

Vulnerabilities detected above a certain severity threshold will block the application build from continuing, forcing developers to address these vulnerabilities immediately.

As with operating system vulnerabilities, the impact of application-level vulnerabilities is assessed by developers and may result in patches, dependency upgrades, or other temporary mitigation measures. This process may also lead to emergency releases to resolve critical vulnerabilities and may result in an Information Security Incident being raised.

Responsibilities

Infrastructure staff is responsible for monitoring, evaluating, and treating system-level vulnerabilities.
Developers are responsible for monitoring, evaluating, and treating application-level vulnerabilities.

Last updated: August 17, 2024

‍