Last Updated: 6/1/2021

The core security measures Jitterbit implements to protect Client Data are outlined in this Jitterbit Security Measures Annex:

Jitterbit Security Policy

This Jitterbit Security Measures document (the “Security Policy”) outlines the administrative, technical and physical measures that Jitterbit undertakes to protect Client Data from unauthorized access or disclosure. Jitterbit has been assessed to meet the requirements of the SOC 1, SOC 2, ISO 27001, US HIPAA Privacy and Security, California Consumer Privacy Act (CCPA) and EU GDPR rules. Jitterbit has a written information security plan to implement the terms of this Security Policy that is reviewed and approved annually by its senior management team. This Security Policy is referenced in and made a part of your Client agreement with Jitterbit (the “Agreement”). In the event of any conflict between the terms of the Agreement and this Security Policy, this Security Policy shall govern with respect to its subject matter. Capitalized terms used but not defined in this Security Policy have the meanings set forth in the Agreement or in the Documentation.

Privacy-by-design: Jitterbit actively keeps data protection and privacy in mind at every step; this includes internal projects, product development, software development, and IT systems.

Privacy by Default: Once Jitterbit releases a product or service to the public, strict privacy settings are applied by default, without any manual input from the user. In addition, personal data provided by the user to enable a product’s optimal use are stored, processed and/or transmitted for only the amount of time necessary to provide the product or service, in accordance with defined standards.

1. Client Data Access and Management

1.1 Client controls access to its account in the Jitterbit Application via User IDs, passwords and two-factor authentication.
1.2 Jitterbit Personnel do not have access to unencrypted Client Data unless Client provides access to its Jitterbit account to such Jitterbit Personnel. “Jitterbit Personnel” means Jitterbit employees and Jitterbit authorized individual subcontractors.
1.3 Jitterbit uses Client Data only as necessary to provide the Jitterbit Application and support to Client, as provided in the Agreement.
1.4 Client application and project metadata generated by the Jitterbit Application is hosted by Jitterbit only in the Jitterbit Application production environment and only within the region from which it originates (i.e. US data stays in the US, EU data stays in the EU and APAC data in APAC region).
1.5 Jitterbit shall create and maintain flow diagram(s) indicating how Client Data flows through the Jitterbit Application. Jitterbit shall provide such flow diagram(s) upon Client’s reasonable request.

2. Logical Separation of Client Data

2.1 Jitterbit Harmony isolates Client Data by using:

• Secure DB Architecture -separated database and separated schema architecture
• Secure Connections or tables – Trusted database connections
• Encryption – obscures critical data so that it remains inaccessible to unauthorized parties even if they come into possession of it. Please see Section 16 for more details.
• Filtering: Using an intermediary layer between a tenant and a data source that acts like a sieve, making it appear to the Client as though its data is the only data in the database.
• Access Control Lists – to determine who can access data in the Jitterbit Application and what they can do withit.

3. Jitterbit Application Infrastructure Access Management

3.1 Access to the systems and infrastructure that support the Jitterbit Application is restricted to Jitterbit Personnel who require such access as part of their job responsibilities.
3.2 Access to system and application logs are restricted to authorized Jitterbit Personnel solely for the purpose of supporting, identifying issues, and improving the Jitterbit Application.
3.2 Unique User IDs, passwords and two-factor authentication credentials over a VPN connection are assigned to Jitterbit Personnel requiring access to the Jitterbit servers that support the Jitterbit Application.
3.3 Server password policy for the Jitterbit Application in the production environment exceeds the PCI-DSS password requirements.
3.4 Access privileges of separated Jitterbit Personnel are disabled promptly. Access privileges of persons transferring to jobs requiring reduced privileges are adjusted accordingly.
3.5 User access to the systems and infrastructure that support the Jitterbit Application is reviewed quarterly.
3.6 Access attempts to the systems and infrastructure that support the Jitterbit Application are logged and monitored by Jitterbit.
3.7 AWS Security Groups have deny-all default policies and only enable business required network protocols for egress and ingress network traffic.
3.8 Firewalls – Jitterbit uses an AWS-supplied security groups firewall behind a load balancer to control access and traffic to and from infrastructure hosts.
3.9 Intrusion Detection – Jitterbit monitors its Lacework.net IDS

4. Risk Management

4.1 Jitterbit’s Risk Management process is modeled on NIST 800-30
4.2 Jitterbit conducts technical and non-technical risk assessments of various kinds throughout the year, including self- and third-party assessments and tests, automated scans, and manual reviews.
4.3 Results of assessments, including formal reports as relevant, are reported to the Information Security Officers and Data Protection Officers. A Security Committee meets biweekly to review reports, identify control deficiencies and material changes in the threat environment, and make recommendations for new or improved controls and threat mitigation strategies to senior management.
4.4 Changes to controls and threat mitigation strategies are evaluated and prioritized for implementation on a risk- adjusted basis.
4.5 Threats are monitored through various means, including threat intelligence services, vendor notifications, and trusted public sources.

5. Vulnerability Scanning and Penetration Testing

5.1 Vulnerability scans using commercial-grade tools are automatically performed quarterly and ad-hoc on systems required to operate and manage the Jitterbit Application. The vulnerability database is updated regularly.
5.2 Scans that detect vulnerabilities, meeting Jitterbit-defined risk criteria, are conducted regularly; priority based notifications are shared with security personnel and addressed.
5.3 Potential impact of vulnerabilities that trigger alerts are evaluated by staff.
5.4 Vulnerabilities that trigger alerts and have published exploits are reported to the Security Committee, which determines and supervises appropriate remediation action.
5.5 Security management monitors or subscribes to trusted sources of vulnerability reports and threat intelligence. 5.6 Penetration tests by an independent third party expert are conducted at least annually.
5.7 Penetration tests performed by Jitterbit Security are performed regularly throughout the year.
5.8 Jitterbit Harmony code is reviewed by internal and external personnel using open-source and commercial-grade tools. Discovered vulnerabilities are assigned criticality levels and are remediated quickly, according to the risk presented and remedial options.

6. Remote Access & Wireless Network

6.1 All access to the Jitterbit VPCs (e.g., Development and Production accounts) require authentication through a secure connection via approved methods such as VPNs and enforced with mutual certificate authentication and two- factor authentication.
6.3 Jitterbit corporate offices, including LAN and Wi-Fi networks in those offices, are considered to be untrusted networks and require successful authentication to the VPN in the AWS accounts for access. Only one member of the IT support team is permitted to securely remotely access the corporate office network to support the firewall, phones and other infrastructure.
6.4 Jitterbit maintains a policy of not storing Client Data on local desktops, laptops, mobile devices, shared drives, removable media, as well as on public facing systems that do not fall under the administrative control or compliance monitoring processes of Jitterbit.

7. Jitterbit Application Location

7.1 Client Data is stored in the available Jitterbit Application Regions: US, EU and AP; the US cloud does not replicate with EMEA cloud (or AP cloud) or visa versa. Each region inside the US does replicate between each other US region.

8. System Event Logging

8.1 Monitoring tools and services are used to monitor systems including network, server events, and AWS API security events, availability events, and resource utilization.
8.2 Jitterbit infrastructure Security event Logs are collected in a central system and protected from tampering. Logs are stored for 12 months.
8.3 Jitterbit Harmony application logs are collected in a central system and protected from tampering. Logs are stored for 90 days

9. System Administration, Malware Prevention and Patch Management

9.1 Jitterbit has created, implemented and maintains system administration procedures for systems that access Client Data that meet or exceed industry standards, including without limitation, system hardening, system and device patching (operating system and applications) and proper installation of threat detection software, malware prevention, and daily signature and heuristic updates of same.
9.2 Employee Internet access is audited with restricted access to blacklisted sites.
9.3 Jitterbit Security reviews US-Cert and other new vulnerabilities announcements weekly and assesses their impact to Jitterbit based on a Jitterbit-defined risk criterion, including applicability and severity.
9.4 Applicable US-Cert and other security updates rated as “high” or “critical” are addressed within 30 days of the patch release.

10. Jitterbit Security Training and Jitterbit Personnel

10.1 Jitterbit maintains a security awareness program for Jitterbit Personnel, which provides initial education, ongoing awareness and individual Jitterbit Personnel acknowledgment of intent to comply with Jitterbit’s corporate security policies. New hires complete initial training on security, HIPAA, CCPA, and GDPR, sign a proprietary information agreement, and digitally sign the information security policy that covers key aspects of the Jitterbit Information Security Policy.
10.2 All Jitterbit Personnel acknowledge they are responsible for reporting actual or suspected security incidents or concerns, thefts, breaches, losses, and unauthorized disclosures of or access to Client Data.
10.3 All Jitterbit Personnel are required to satisfactorily complete annual security training. Periodic reminders and proactive phishing training are delivered regularly.
10.4 Jitterbit performs criminal background screening as part of the Jitterbit hiring process, to the extent legally permissible.
10.5 Jitterbit will ensure that its subcontractors, vendors, and other third parties that have direct access to the Client Data in connection with the Jitterbit Applications adhere to the applicable data security standards as defined by Jitterbit in Policy and Procedures, which is a combination of ISO 27001/27002, NIST 800-53, CIS, CSA and CERT, HIPAA and GDPR requirements.

11. Physical Security

11.1 The Jitterbit Application is hosted in AWS and all physical security controls are managed by AWS. Jitterbit reviews the AWS SOC 2 Type 2 report annually to ensure appropriate physical security controls.

12. Notification of Security Breach

12.1 A “Security Breach” is (a) the unauthorized access to or disclosure of Client Data, or (b) the unauthorized access to the systems within the Jitterbit Application that transmit or analyze Client Data.
12.2 Jitterbit will notify Client in writing without undue delay within seventy-two (72) hours of a confirmed Security Breach.
12.3 Such notification will describe the Security Breach and the status of Jitterbit’s investigation. 12.4 Jitterbit will take appropriate actions to contain, investigate, and mitigate the Security Breach.

13. Disaster Recovery

13.1 Jitterbit maintains a Disaster Recovery Plan (“DRP”) for the Jitterbit Applications. The DRP is tested annually. 13.2 The Jitterbit Application is managed in different AWS Regions as standalone deployments, which can be employed as part of Client’s DRP strategy. To effectively use the cross-regional availability of the Jitterbit Application for disaster recovery purposes, Client is responsible for the following:
13.2.1 Requesting additional Jitterbit Application accounts in different regions to support its DRP program. 13.2.2 Managing its data replication across applicable regions.
13.2.3 Configuring and managing its Jitterbit accounts.
13.2.4 Managing backup and restoration strategies.

14. Jitterbit Security Compliance, Certifications, and Third-party Attestations

14.1 Jitterbit hires accredited third parties to perform audits and to attest to various compliance and certifications annually including:
14.1.1 SOC 2 Attestation Report
14.1.2 SOC 1 Attestation Report
14.1.2 HIPAA Compliance Report for Business Associates
14.1.3 GDPR Compliance Report
14.1.4 Penetration Testing Report Summary
14.1.5 Vulnerability Assessment Report Summary
14.1.6 ISO 27001 Attestation Report
14.1.7 CCPA Compliance Report for California Privacy Act

15. Jitterbit Cloud and Local Agent

15.1 Jitterbit Harmony Cloud has been designed with the highest security settings in mind so that even simple implementations (lower security requirements) can take advantage of this “baked in” high-security.
15.2 Jitterbit provides an implementation option (Local Agent) for Clients who choose to process sensitive data outside of the Jitterbit cloud infrastructure and behind their own firewall and corporate network.

16. Data Encryption

16.1 Encryption of Client Data at rest on Harmony: Harmony Cloud data is encrypted at-rest with an AES-256 FIPS 140- 2 algorithm. For more details, review the Jitterbit Harmony Architecture and Security Whitepaper at: https://success.jitterbit.com/display/DOC/Jitterbit+Security+and+Architecture+White+Paper
16.2 Encryption of Client Data in transit to/from Harmony: Harmony Cloud data is encrypted in-transit using HTTPS (TLS 1.2), SSH and/or IPsecSsEC. For more details, review the Jitterbit Harmony Architecture and Security Whitepaper at:https://success.jitterbit.com/display/DOC/Jitterbit+Security+and+Architecture+White+Paper

17. Client Responsibilities

17.1 Client is responsible for managing its own user accounts and roles within the Jitterbit Application and for protecting its own account and user credentials. Client will comply with the terms of its Agreement with Jitterbit as well as all applicable laws.
17.2 Client will promptly notify Jitterbit if a user credential has been compromised or if Client suspects possible suspicious activities that could negatively impact security of the Jitterbit Application or Client’s account. Client may not perform any security penetration tests or security assessment activities without the express advance written consent of Jitterbit.
17.3 For Jitterbit Applications which are not hosted by Jitterbit, Client is responsible for updating its Jitterbit Client Software whenever Jitterbit announces an update.
17.4 Clients are responsible for managing a backup strategy regarding Client Data.
17.5 Clients whose Client Data includes PCI, PHI, GDPR, PII or other sensitive data should implement Jitterbit-provided IP whitelisting and multi-factor authentication (MFA) in the Jitterbit Application and consider the use of the Local Agent, with additional limited logging configuration.