Orbit transition support and FAQs

Bynder Orbit Knowledge base

Orbit security and compliance

You want your data to be safe in Orbit. We can guarantee it is. We have Orbit's security at heart and we make sure we are compliant with the current and widely-recognized security standards.


We host data on the Amazon S3 server in Ohio, US East (us-east-2). We also use CDN and transfer acceleration so downloads and uploads are always as quick as possible. For more information, see Amazon transfer acceleration and S3 regions.

Our certification and compliance

We currently hold the following certifications and comply to the following requirements:

  • ISO27001:2013
  • HIPAA compliance
  • 95/46/EC

Compliance with the following is planned:

  • Payment Card Industry Data Security Standard (PCI-DSS) v3.1
  • ISO 22301:2012
  • General Data Protection Regulation

Supported communication protocols

From July 2017 onwards, Orbit will only be supporting the TLS 1.2 protocol (and newer versions). This means that some browsers and applications, such as Internet Explorer 10 and Java 7 and older, will not be able to connect with Bynder. Internet Explorer 11 and newer, and Java 8, will continue to work as before.

We recommend that you upgrade your browser to the latest available version.

Security alerts and tests to ensure compliance

We monitor our security procedures on a regular basis and have the following alerts in place so that immediate action can be taken:

  • File integrity monitoring system is in place to alert personnel of unauthorized modifications to critical systems.
  • All security alerts are monitored, analyzed, and distributed to appropriate personnel.
  • The security alerts from Intrusion Detection Systems (IDS) are monitored for critical alerts 24 hours a day, 7 days a week. The latest IDS signatures are installed automatically.
  • Third-party-managed, or internal penetration tests, or “red team” exercises against networks, hosts, and applications are in place and performed at least once a year as required by our ISO27001 implementation. The code is manual penetration tested by Madison Gurkha on an annual basis. Additionally we have weekly automated vulnerability scanning (by Qualys).

Security management and policies

Security policies are documented in our Information Security Management System (ISMS) control document, are approved by the management, and enforced continuously through monitoring and internal audits. All changes to policies are communicated, and trainings are provided to make sure everyone keeps abreast of the requirements.

Our information security strategy is reviewed annually by Chief Information Security Officer, and is translated into information security policy (ISP). Additionally, any contracts with third parties require conformity with Bynder security policies. Third parties must provide assurance (certification or an evidenced strong internal security program) of actively protecting their customers’ data or results from recent penetration tests. Additionally, third parties must accept liability for any incidents and sign acceptance against our ISP.

We have clear incident response procedures and incident handling and escalation procedures in place. For the top 10 identified risks we have a clear response plan ready, also there’s a fallback incident escalation plan for situations that do not fit the previously identified risks.

Network security

Our Infrastructure Design defines the used security levels and networks used internally. NAT is implemented in out environment to hide the internal network from the Internet, and all the external connections are approved in the course of a formal procedure. Additionally, as required by our ISO27001:2013 implementation, we perform vulnerability assessments or penetration tests on your Internet-facing connections at least once a year and after any significant modifications.

The firewall rules are reviewed monthly, and firewall logs and IDS logs are used for qualification. Logs are retained indefinitely and are checked continuously and automatically for malicious behavior.

Policies and procedures are established, supporting business processes and technical measures implemented, to protect wireless network environments, including the following:

  • Perimeter firewalls implemented and configured to restrict unauthorized traffic.
  • Security settings enabled with strong encryption for authentication and transmission, replacing vendor default settings (e.g., encryption keys, passwords, and SNMP community strings).
  • User access to wireless network devices restricted to authorized personnel.
  • The capability to detect the presence of unauthorized (rogue) wireless network devices for a timely disconnect from the network.

Operations security


System security patches are installed automatically when they become available in the OS Maintainer’s repositories using “unattended upgrades”. The application is not patched due to our release-mechanism that completely builds the application servers from scratch with every new version of the application. Changes to the application are tested thoroughly and problems with external or internal systems are identified early in the process, making it possible to circumvent issues with broken external systems. With separation of processes in our cluster broken systems are easily quarantined and dealt with separately. By minimizing the OS or platform level software, the risk a system is impacted by patches is minimized.

Malware protection

Production servers are rebuilt more than once a day from scratch as part of our continuous deployment mechanisms and as such all malware that might have been installed due to a security breach will be automatically destroyed. We do not scan clients in our network, but we do scan the network itself.


We back up data with continuous replication and use GPG to encrypt our backups. The recovery point objective (RTO) is 1 hr, and the recovery time objective (RPO) is max 24hrs. The details of our backup policy have been laid out in the SLA.

What next...