Cybersecurity policy

1. Scope and applicability

This policy describes the technical and organizational measures by which Purde Software protects its data and technology infrastructure, the apps it develops for the Atlassian Marketplace, and the data of its customers and users.

It applies to all employees, contractors, and (to the extent indicated) suppliers acting on Purde Software's behalf.

This policy supplements the Privacy Policy, the Service Level Agreement, and the Business Continuity Plan.

1.1 Proportionality

Purde Software is a two-person, part-time business developing apps for Confluence Data Center and Cloud. The measures in this policy are proportionate to the nature, scale, and risk profile of our processing, in line with Art. 32 GDPR and the proportionality principle expressed in ISO/IEC 27001:2022 §6.1. We do not maintain a full ISMS or formal certification; instead, we apply a defined set of controls and review them at least annually.

2. Roles and responsibilities

There is no separate CISO function and no Risk Committee; given our scale, these roles are consolidated in the Owner.

3. Information assets

We maintain a lightweight inventory of the assets used to develop and operate our apps. The inventory is reviewed at least annually.

• Devices: development laptops/workstations used by the Owner and contractors.

• Source code repositories: Bitbucket Cloud (primary).

• Cloud production infrastructure: AWS (Frankfurt, Ireland) and Heroku (Ireland), being migrated to Atlassian Forge between end of 2025 and mid 2026.

• SaaS and developer tools: Atlassian Cloud (Confluence, Jira, Service Desk, Marketplace admin), Bitbucket, Snyk, Google Workspace (Gmail), Betterstack, OpenAI (for the Smart Q&A AI feature).

• Customer data: none stored beyond what is required for app installation/operation; see the Privacy Policy for details.

4. Workstation and endpoint security

• Operating system: kept at a vendor-supported version with automatic security updates enabled.

• Full-disk encryption: enabled on all development laptops (FileVault on macOS / BitLocker on Windows).

• Screen lock: automatic after 5 minutes of inactivity; required after every wake.

• Anti-malware: state-of-the-art anti-malware/anti-virus enabled on all devices.

• USB drives, SD cards, and other removable media: we do not insert removable media we do not trust.

• Mobile devices: secured with PIN, password, or biometric access protection; remote wipe enabled where the device accesses business data.

• Email: we do not open attachments from senders we do not trust; suspicious messages are reported and deleted.

• Software installation: only from trusted sources (vendor sites, official package managers, vetted Marketplace listings).

5. Identity, access, and authentication

• Multi-factor authentication (MFA) is enforced on every relevant business account: Atlassian, AWS, Heroku.

• Strong passwords are required Passwords are not reused across services. Where vendors enforce expiration, we comply; otherwise we rotate on a risk basis (e.g., after a confirmed compromise or personnel change).

• Least privilege: each account receives only the permissions needed for its role.

• Privileged access (production AWS/Heroku/Atlassian admin, Bitbucket admin) is restricted to the Owner and reviewed annually.

• Secrets management: API keys, tokens, and credentials live only in provider-managed secret stores (AWS Secrets Manager, Heroku config vars, Forge KVS) or the password manager. Secrets are never committed to source control; pre-commit and Bitbucket-side scans flag accidental exposure.

• Source-code access: Bitbucket repositories use branch protection on the main branch and require the second contributor's review for production releases.

6. Cloud infrastructure security

• Providers: we use only well-established providers (AWS, Heroku, Atlassian Forge).

• Region: production data is hosted in the EU (Frankfurt and Ireland).

• Network exposure: services expose only HTTPS endpoints; unused ports are closed; servers are hardened to minimize attack surface.

• MFA: enforced for all administrative access (see 5).

• Patching: managed services (Heroku, AWS Lambda, Forge runtime) are patched by the provider; container images and dependencies under our control are rebuilt on dependency updates and at least quarterly.

• Encryption in transit: TLS for all client and inter-service traffic.

• Encryption at rest: provider-default encryption for all storage volumes, databases, and object storage.

7. Secure software development

We follow these principles for every change to our apps:

• Cloud apps comply with Atlassian's Marketplace security requirements.

• All user input (forms, APIs, cached data) is escaped before output.

• All REST endpoints and servlets verify the current user's permissions on the server side before performing any action; permission checks are never client-side only.

• GET requests are not used for state changes (CSRF protection).

• When a request returns data drawn from multiple content entities, view permission is verified per entity before inclusion in the response.

• Responses include only the data necessary for the use case.

• We minimize the number of third-party libraries used; remaining dependencies are reviewed for known vulnerabilities before adoption and continuously thereafter.

• Cloud apps store no customer data beyond what is required for app installation and operation.

• Log output is minimized.

• Production releases require review by the second contributor.

7.1 Static analysis (SAST)

All app source code is continuously scanned with Snyk Code, with security-relevant findings triaged before release.

7.2 Dependency / software composition analysis (SCA)

All dependencies are continuously monitored with Snyk for known vulnerabilities. Vulnerabilities are remediated as soon as a compatible upgrade is available.

7.3 Dynamic analysis and penetration testing

Cloud apps participating in Atlassian's Cloud Security Participant program undergo a penetration test before joining the program and again after major changes. For other apps, dynamic testing is performed on a risk basis.

8. Vulnerability and patch management

• Workstations: OS and application updates are installed automatically or within 7 days of release for security updates.

• Cloud infrastructure: managed-service patches applied by the provider; self-managed components rebuilt on dependency updates and at least quarterly (see 6).

• App dependencies: Snyk-flagged vulnerabilities are remediated according to the SLA timelines for the corresponding CVSS severity.

• Vulnerability disclosure: anyone can report a suspected vulnerability via our service desk or by emailing support@purde.de marked "security.

When we identify a vulnerability in our apps, we notify Atlassian via the AMS project and, where the CVSS v3.1 base score is High or Critical (≥ 7.0), we notify affected customers using the licence data provided by the Atlassian Marketplace, following the Atlassian app vulnerability notification template.

9. Logging, monitoring, and protection of data in logs

• A defined set of operational logs is collected for troubleshooting and security analysis.

• Logs are minimized at source: only data necessary for the operational purpose is recorded; personal data is avoided where possible.

• Log retention: 30 days for Cloud app request logs (AWS/Betterstack); 7 days for Slack-integration and Simple Cite logs. Logs are automatically deleted at the end of the retention period.

• Logs are reviewed when an incident is suspected and on an ad-hoc basis as part of operational work.

10. Backup and recovery

• Source code: Bitbucket holds the primary copy.

• Build and release artifacts: rebuildable from source at any commit hash.

• Customer data in our infrastructure: minimal (installation metadata only); restored by re-installing the app from the Marketplace.

• Restore tests: performed at least annually as part of the BCP review.

• Recovery objectives: RTO 48 hours, RPO 24 hours for our Cloud apps.

11. Incident response

We follow a lightweight incident-response process:

1. Detect — events come in via monitoring alerts, Atlassian/Snyk notifications, customer reports, or our own observation.

2. Triage — the Owner classifies severity (Critical / High / Medium / Low).

3. Contain and eradicate — credentials rotated, vulnerable versions disabled, fixes deployed.

4. Notify — affected customers are informed without undue delay; for personal-data breaches, within 72 hours of becoming aware (see Privacy Policy §10). Atlassian is informed via the AMS project where Marketplace apps are involved.

5. Recover — service restored from backups or by redeployment.

6. Learn — a short post-incident note is recorded with the root cause and corrective actions.

A separate, more detailed Incident Response Plan will be published.

12. Supplier and subprocessor security

We engage only well-established suppliers for our infrastructure and tooling. The current Subprocessor Register and the criteria we apply (EU location preference, recognized certifications such as ISO/IEC 27001 or SOC 2, public security and privacy commitments) are documented in the Privacy Policy 8. Material changes to subprocessors are notified to customers at least 30 days in advance.

13. Personnel security

• Onboarding: new contributors receive accounts on a need-to-know basis with MFA enforced from day one; this policy and the Code of Conduct are reviewed before any access to customer data or production systems.

• Awareness: contributors receive security and privacy training in their primary employment; we additionally maintain awareness via this policy, the Privacy Policy, and operational discussions on relevant incidents and Atlassian advisories.

• Confidentiality: all contributors are bound by confidentiality obligations.

• Offboarding: when a contributor leaves, all access (Atlassian, Bitbucket, AWS, Heroku, password manager, signing keys, email forwarding, Snyk, Marketplace admin) is revoked within 24 hours and verified within 7 days. Devices are wiped or returned.

14. Business continuity

Continuity arrangements (lean two-person team, open-source availability of most apps, source-code access on request, source-code mirror, escrow on request) are described in the Business Continuity Plan.

15. Audits, reviews, and metrics

• Workstation/endpoint controls: reviewed at least once per year.

• Cloud infrastructure controls: reviewed at least once per year.

• App security controls: reviewed at every relevant change and at least once per year per app.

• This policy: reviewed at least annually and after any significant change to our infrastructure, products, or applicable regulation.

• Internal audit results are documented at https://purde-software.atlassian.net/wiki/spaces/PLUG/pages/1765998612 (internal use only).

• Our self-assessment against the CAIQ-Lite questionnaire is published for customer review.

16. Related documents

• Privacy Policy

• Data Processing Agreement (DPA)

• Service Level Agreement

• Business Continuity Plan

• End User License Agreement (EULA)

• Code of Conduct

• CAIQ-Lite questionnaire

17. Version history