This page explains our security posture, which aims to assist customers in meeting their own compliance requirements.

Compliance

SOC2

The Plugin People has as of 23 APR 2024 attained SOC2 type 1 compliance. SOC2 Type 2 Audit was completed 22 JUL 2024. In scope are the core business processes, as well as our cloud infrastructure that is specific to our business and the development/deployment/support of Enterprise Mail Handler for Jira Cloud.

You can view our Trust Center online: https://trust.thepluginpeople.com/, SOC compliance attestation by our external auditor can be found in the resources section.

GDPR

The Plugin People have outsourced the Data Protection Officer role; audits are expected soon.

HIPAA

Specific to our Enterprise Mail Handler app for Jira Cloud: We do not currently have a HIPAA compliance program underway. See our HIPAA page for how we work toward this.

Governance

The Plugin People establish policies and controls, monitor compliance with those controls, and prove our security and compliance to third-party auditors.

Our policies are based on the following foundational principles:

Access should be limited to only those with a legitimate business need and granted based on the principle of least privilege
Security controls should be implemented and layered according to the principle of defense-in-depth
Security controls should be applied consistently across all areas of the enterprise
The implementation of controls should be iterative, continuously maturing across the dimensions of improved effectiveness, increasingly auditable, and decreasing friction

Data Protection

Data at rest

From our Records of processing activities (ROPA, GDPR Article 30) page:

File stores used for storing inbound/outbound customer email data are encrypted at rest.

Databases used in production are encrypted at rest. Additional field Level encryption (prior to storage) is used on sensitive data.

When flagging mail for support, that mail content remains in its source region, is only retrieved at the point of need by The Plugin People.

Data in transit

The Plugin People follow Atlassian guidelines (see https://developer.atlassian.com/platform/marketplace/app-security-guidelines/) on minimum transport security ciphers.

TLS version 1.2 is used for all public facing network access. HSTS (HTTP Strict Transport Security) is enabled with a maximum age of at least one year. Server TLS keys and certificates are managed by AWS.

Inbound / Outbound mail connections all support SSL/TLS connectivity. 3rd party integrations like Slack and SMS provider web gateways are only accessible over secure connections.

Data Residency

See Data Residency for more information.

Secret management

Key management is delegated to AWS wherever possible making rotation automated. Best practice Role based security is applied to all application nodes.

Product Security

Penetration Testing

Penetration testing is carried out annual as part of the SOC2 audit.

Public Bug Bounty

The Plugin People have an open public bug-bounty (https://tracker.bugcrowd.com/plugin-people).

Vulnerability Scanning

We make use of static analysis tools (https://www.sonarsource.com/products/sonarqube ) as well as dependency analysis triggered at build time (https://snyk.io/).

Enterprise Security

Endpoint protection

All corporate devices are Linux based and use full desk encryption, have regular software updates, use screen-locks and password managers that are themselves encrypted and password accessible. USB devices are rarely needed but are full disk encrypted if used.

Two factor authentication (2FA)

Two factor authentication is used on all enterprise systems that support it, as well as our own management apps.

Remote access

Remote access to our office network is not possible. Remote access (other than through AWS console using 2FA) is not possible.

Education

All staff receive on-boarding security awareness training. Any vulnerabilities found are discussed with the team to share learning.

Identity and access management

Access to AWS infrastructure is strictly limited, granted through Change Control, and scoped to having Roles for permissions. Removing such access is handled through our termination process.

Data Privacy

We are very aware that your sensitive data flows through our app/system and are very clear that your data is yours, we make no use it beyond what you would expect to deliver the functionality of the app.

Our Roadmap for Forge, RoA, Gov Cloud, Isolated Cloud

Roadmap - Step 1: Migrate all Connect modules to their Forge variant

IN PROGRESS

Currently JEMHC is “Connect on Forge”. As Connect framework is now deprecated we need to migrate to Forge framework entirely but currently have some missing Forge functionality preventing this. As of MAR 2026 Atlassian has a 3 month window for collating all these vendor blockers.

Part of this will be migrating away from legacy “Connect” course grained scopes to fine grained Forge permissions.

ETA: Q4 2026

Roadmap - Step 2 : Gov Cloud / FEDRamp

GovCloud requires us to run a dedicated cloud stack for those customers only, this is achievable for us, its just running another stack of the app (as we already do with a Germany based stack of the app).

There are a range of additional restrictions and limitations that are quite similar to what we already do for the current public JEMHC app.

ETA: Q4 2026

Roadmap - Step 3: Runs On Atlassian

In order to be ‘Runs on Atlassian’ apps must not only be fully Forge (step 1), they must also “run” on Atlassian, meaning the entire application stack deploys to Atlassian, we have a lot of infrastructure to provide the necessary scalability we need, to do all that on Atlassian presents a few chunky challenges:

To achieve RoA all our code must execute via Forge, this is huge for us as all our app functionality is remote, accessed throughhttps://developer.atlassian.com/platform/forge/remote/.
Atlassian doesn’t give us all the functionality we currently make use of in our AWS cloud, impacting the app functionality
Atlassian Forge has some significant limits and restrictions that at minimum impact performance of timlieness of processing, worst case it may stop the app and/or require us to limit what we do, or even mean some features need to be completely removed - future analysis required!
Atlassian will bill vendors (us!) for all customer Forge invocations, which at scale can result in quite the large bill and represents a large change from our currently ‘cost optimized’ self hosted infrastructure.
Last but not least, we have a management app to help us help customers, to allocate more capacity (Data Packs and Capacity Plan Upgrades) as well as manage the internals of the system itself. How we even do this is not yet even being considered.

So, there is a huge amount of work to get to RoA…

No ETA at this time.

Roadmap - Step 4: Isolated Cloud

This is far in the future and requires us to consider/rework how Capacity is allocated and managed (at the least) as well as dealing with specific Atlassian requirements of this deployment model.

No ETA at this time.