55 Degrees Security Practices

Last Updated: December 20, 2023
This document will be updated when our Security Practices are changed to reflect any new practices adopted.

55 Degrees knows security is critical yet hard to perfect. Thus, we are always improving our practices. Please visit the trust page on our website and, if needed, visit our external trust center where you can download compliance certificates and audit reports as well as learn more about process and policies.

Our Security Practices should be read in conjunction with the 55 Degrees Privacy Statement and Policies and your Customer Agreement: Cloud Products | On-Prem Products.

Please contact us via our Support Portal at https://support.55degrees.se if you have any questions.

We're ISO 27001 Certified and SOC 2 Type II compliant

Visit our compliance page to read more and find out how to access our certificate and audit reports.

Our embedded Cloud products

We offer many apps as embedded apps within the Atlassian Jira and Azure DevOps Cloud platforms. When we can, we store all your data on the host Cloud instance. In some cases, this might not be possible due to the size of the data asset, the security sensitivity of the data, and the general limitations of what's capable with the available APIs. When your data is stored on the host Cloud instance, the app needs to be installed on your instance in order for us to retrieve it. In the cases where data needs to be stored on our database, we'll use the appropriate security techniques, such as using encryption and general checksum hashing for data.

We do not conduct penetration testing as our infrastructure providers, Amazon Web Services, DigitalOcean, Azure DevOps, and Atlassian, do not permit penetration testing on their infrastructure (based on their license and usage agreements). Having said that, we subject any public-facing pages to continuous monitoring via services such as Detectify to ensure we are aware of any issues that might have cropped up, and we do follow the Amazon and Atlassian guidelines for security:

• App Security Incident Management Guidelines for Atlassian Marketplace Vendors

• Security Guidelines and Best Practices for Atlassian Marketplace Vendors

Our On-Premise products

Our on-premise products are completely hosted on your hardware. These products do not need to reach out via the internet. We access, process, or store zero data outside of your hardware. We don't even employ usage analytics! In this case, you are fully in charge of your own security. Note that we do have a DPA for our on-prem customers, but the data transfers mentioned are entirely focused on ancillary platforms such as our support portal.

General operational measures

We maintain a full set of policies, documents, and tests as part of our Information Security Management System (ISMS). However, we have captured some highlights of our general optional measures below. The operating principle we use is “Trust, but verify.” We teach people to do the right thing and trust that they will always aim to do that. But, we have to verify continually to ensure that is the case.

1. Access Control

1.1. Outsourced processing: We host our infrastructure with outsourced cloud infrastructure providers, such as AWS, that comply with programs such as ISO 27001 and SOC 2. We rely on contractual agreements, privacy policies, and vendor compliance programs in order to protect data processed or stored by these vendors. Review the vendors we use for processing personal data.

1.2. Physical and environmental security: Each service has its own CloudFront and independent architecture for each environment in our SDLC.

1.3. Authentication: Customers interacting with the products via the user interface must authenticate before accessing non-public customer data.

1.4. Authorization: Customer Data used for authorization is stored in multi-tenant storage systems accessible to Customers via only application user interfaces and application programming interfaces. Customers are not allowed direct access to the underlying application infrastructure. The authorization model in each product is designed to ensure that only those with the necessary permissions can access end-user personal data.

2. Back-Ups

2.1. External solutions: Where we use external solution providers to provide a service, we rely on their backup systems. Backups are for Disaster Recovery purposes. We require all backups to be encrypted at rest and limit the duration of their storage.

3. Logging of access to personal data

3.1. External solutions: Where we use external solution providers to provide a service, we rely on their internal logging capabilities to audit how users use the systems.

3.2. Internal solutions: For any internal custom solutions, we build access controls either at the network and/or system level and/or the application level as necessary.

4. Authorization and permissions

4.1. Principle of least access: Team members are only given access to the systems absolutely necessary for them to perform the duties required of their jobs. Team members only have access to tools and data they absolutely must have to complete their work. All requests for system access must go through a centralized approval process before system access is granted. These access requests are checked and audited regularly.

4.2. Frequency of access: Employees will only access customer data for purposes of application health monitoring, performing system updates, application maintenance, and/or upon customer request for support purposes.

4.3. VPN: Production infrastructure access is locked down and requires trusted VPN access. Our automation and monitoring reduce the amount of access needed.

4.4. ​Password vaults: All team members make use of Password Vaults to maintain a randomly generated password for each service and use Two Factor Authentication for the Infrastructure providers that are able to support it.

4.5. Change approval process: All security changes are conducted after approval by both co-founders.

4.6. Access Reviews: We review all system access at least quarterly to ensure no one has access to any systems they shouldn't. We track these review requests and outcomes for audit purposes.

5. Encryption of data communication

5.1. Protection: Communication between Cloud products and the 55 Degrees servers is done using HTTPS/SSL requests. All web requests are digitally signed, authenticated, and authorized. 55 Degrees' servers are only accessible through secure protocols (e.g., HTTPS and/or ssh).

5.2 On-Premise Instances: There is no data communication between 55 Degrees servers or subprocessors and any customer using an On-Premise application.

6. Firewalls

6.1 A firewall protects every application (both internal and customer-facing). The firewalls are configured to be application- and environment-specific (staging, production) specific.

7. Virus and malware protection

7.1. All systems shall be built from original, clean master copies to ensure that viruses are not propagated.

7.2. Up-to-date anti-virus software for detecting, removing, and protecting against suspected viruses shall be installed on all servers, workstations, and laptops. Updates of the software will happen automatically so that each server, workstation, and laptop has the latest anti-virus patches and/or signatures.

7.3. Employees shall maintain awareness of current anti-virus procedures and policies and must immediately report any potential virus and malware infections to their manager and to the CTO.

7.4. Upon notification of a virus infection, systems shall be isolated from the network, scanned, and cleaned appropriately. Any removable media or other systems to which the virus shall have spread shall be treated accordingly.

7.5. If a system has been identified as potentially infected and removal/quarantine of the virus/malware cannot be definitively proven, the system shall be completely wiped and re-imaged.

7.6. Users or Subscribers impacted by virus-related security incidents shall be notified as soon as reasonably possible in alignment with Security Incident Response Procedures.

8. Separation of environments

8.1. Development, test, production, and demo environments are segregated.

9. Software Development Policy

55 Degrees requires that employees:

9.1. Manage all code through a version control system to allow viewing of change history and content.

9.2. Perform vulnerability testing as a component of QA testing for major changes and address any high or critical findings prior to software release.

9.3. Ensure that software is released only via our automated continuous delivery tools, with no production server access needed by the product development teams.

9.4. Prioritize security fixes and improvements within the time frames stipulated for a given incident severity level.

9.5. Develop all web applications (internal and external, including web administrative access to the application(s) based on secure coding best practices. We strive to prevent common vulnerabilities in software development processes, including the following:

• Injection

• Broken Authentication

• Sensitive Data Exposure

• XML External Entities (XXE)

• Broken Access Control

• Security Misconfiguration

• Cross-Site Scripting (XSS)

• Insecure Deserialization

• Using Components with Known Vulnerabilities

• Insufficient Logging & Monitoring

9.6. Attend security and vulnerability awareness training containing curriculum approved by 55 Degrees at least once per calendar year.

10. Security Reviews

10.1. All third-party integrations, libraries, etc., are vetted for their security and compliance stance and their licensing agreements prior to use. In addition to this, at build time, we scan for third-party library vulnerabilities whenever possible using external services.

10.2. We employ monitoring to alert us to certain activities like deployments and configuration changes. We also periodically review the infrastructure of our apps manually to verify configurations and settings.

10.3.​ Security reviews of an application are conducted whenever a major change in functionality is implemented and on an ad-hoc basis.

10.4. All products we sell through the Atlassian marketplace are enrolled in the Atlassian Bug Bounty program through BugCrowd.

10.5. As our Cloud apps are static applications (as of the current date), penetration tests aren't applicable. Therefore, we use continuous monitoring services instead so that we always know up-to-date information about which vulnerabilities our Cloud applications are exposed to.

​11. Product-specific security and privacy information

11.1. In every product, we strive to access, process, and store as little data as possible - personal or otherwise.

11.2. Because each 55 Degrees product works differently, we publish a “Data Security & Privacy Statement" for each product via our Support Portal. These documents should answer how your data is retrieved, stored, and processed by the application. It should also contain answers to app-specific security concerns.

11.3. Our supplier and sub-processor page states, as clearly as possible, which vendors are used for which products and via which user interactions.