Information Security Policy (Labele Cloud)

Document ID: VLC-SEC-001 Version: 1.1 Effective: May 2026 Review: Annual

1. Purpose & Scope

Purpose

This policy establishes the security principles, controls, and responsibilities that govern the development, operation, and maintenance of Vamhi Label Cloud. A Jira Cloud app built on the Atlassian Forge platform that provides colored, manageable custom labels for Jira projects.

This policy exists to protect the confidentiality, integrity, and availability of the app and of any customer data processed within it; to meet Atlassian Marketplace partner security requirements; and to provide transparency to customers about Vamhi's security posture.

Scope

This policy applies to:

• All Vamhi team members involved in the development, deployment, or support of Vamhi Label Cloud

• All systems, tools, repositories, and accounts used to build and operate the app

• All third-party services and dependencies used by the app

Infrastructure NoteVamhi Label Cloud is deployed exclusively on Atlassian's Forge serverless platform. All underlying infrastructure security — including physical security, network security, encryption, and data centre controls — is Atlassian's responsibility. This policy covers Vamhi's application-layer and operational responsibilities only.

What the app processes

Vamhi Label Cloud processes Jira label names and issue association data within the customer's Atlassian Forge/Jira environment. The app does not process, store, or transmit personal data, sensitive regulated data, or any data outside of Atlassian's Forge infrastructure.

2. Roles & Responsibilities

Vamhi Team Responsibilities

• Team Lead: Policy owner, approves changes, authorizes access provisioning, oversees security reviews

• Developers: Follow secure coding practices, conduct peer code reviews, report security issues immediately

• All team members: Comply with this policy, complete security awareness training, report incidents promptly

3. Access Control

Principle

Access to all Vamhi systems, repositories, and accounts is granted on the principle of least privilege. Team members receive only the access necessary for their specific role.

Provisioning

• New team members are granted access only after explicit authorization by the Team Lead

• Access rights are documented and maintained in an access inventory

• Privileged access (repository admin, deployment authorization) is restricted to designated team members only

De-provisioning

• All access is revoked within 24 hours of a team member leaving or changing roles

• De-provisioning covers repositories, Forge developer accounts, CI/CD tools, and shared credentials

• De-provisioning is confirmed and recorded by the Team Lead

Review

Access rights are reviewed at least annually and immediately upon any team membership change.

Separation of Duties

• All code changes require peer review and pull request approval before merging

• No single team member may write and deploy code to production without approval

• Production deployments require authorization from the Team Lead or designated approver

Known Gap — MFAMulti-factor authentication is not currently enforced across all team member accounts. Enforcing MFA on all development tools, repositories, and Atlassian developer accounts is a priority improvement item scheduled for implementation.

Forge Permission Scopes

The app requests only the minimum Jira API permission scopes required for its core functionality. Scopes are reviewed with each release.

4. Cryptography & Key Management

Encryption at Rest

All data stored by the app resides within Atlassian Forge's storage infrastructure, which encrypts all data at rest using AES-256. Vamhi does not configure, manage, or hold encryption keys for data at rest.

Encryption in Transit

All communications between the app and Jira APIs are encrypted using TLS 1.2 or higher, enforced automatically by Atlassian's Forge infrastructure.

Key Management

Cryptographic key generation, rotation, revocation, and destruction for infrastructure-level encryption is managed entirely by Atlassian. Vamhi holds no cryptographic keys.

CI/CD Secrets Management

• All secrets (Forge deployment tokens, API credentials) are stored as encrypted environment variables in the CI/CD platform — never hardcoded in source code or config files

• Secrets are rotated when team members leave or when a potential exposure is suspected

• Repository scanning via Snyk detects any accidental secret exposure in code

• Access to pipeline secrets is restricted to authorized team members only

Dependency Integrity

npm dependencies are managed via lockfiles (package-lock.json), ensuring package integrity checksums are validated during installation.

5. Application & Development Security

Secure Development Lifecycle

• Security requirements are identified and discussed at the start of each feature or change

• Peer code review is mandatory for all changes before merging — no direct commits to the main branch

• All changes are tested in a staging environment before production deployment

• Production deployments go through Atlassian's Forge deployment pipeline

Security by Design

• Least privilege: The app requests only the minimum Forge/Jira permission scopes needed

• No external data egress: Customer data is not transmitted outside Atlassian's Forge infrastructure

• Input validation: All user inputs are validated to prevent injection vulnerabilities

• Privacy by design: No personal data is collected beyond what is strictly required

SCA Scanning

Software Composition Analysis scanning is performed on all npm dependencies using Snyk and Akidio. Scanning runs automatically on code changes. Identified vulnerabilities are remediated per the Vulnerability Management policy (Section 12).

Rollback

All production deployments can be rolled back to a previous known-good version via Forge CLI.

6. Change Management

Change Process

• Proposal: Change is described and tracked in the development backlog

• Development: Change is implemented on a feature branch, not directly on main

• Review: Pull request raised; at least one team member reviews and approves

• Testing: Change is tested in staging and verified against acceptance criteria

• Deployment: Deployed to production via Forge CLI, authorized by Team Lead or designated approver

• Monitoring: Post-deployment behaviour monitored via Forge logs

Emergency Changes

Critical security patches may be fast-tracked. Even in emergencies, peer review is required before deployment. Emergency deployments are documented retrospectively within 24 hours.

Configuration Baseline

All configuration is version-controlled in Git, providing a full audit trail of all changes.

7. Incident Response

Severity Classification

Response Steps

• Detect & Report: Any team member who identifies an incident immediately notifies the Team Lead

• Contain: Immediate steps taken to limit impact — revoking access, rolling back a deployment, or disabling a feature

• Assess: Team Lead assesses scope, severity, and affected parties

• Notify: Atlassian notified per the Marketplace Partner Agreement; affected customers notified as required by law

• Remediate: Root cause addressed, fix developed, reviewed, and deployed

• Review: Post-incident review conducted within 5 business days; findings documented and improvements added to backlog

Breach Notification

In the event of a security breach affecting customer data, Vamhi will notify Atlassian and affected customers in accordance with the Atlassian Marketplace Partner Agreement and applicable data protection regulations (including GDPR where applicable).

8. Data Security & Privacy

Data Processed

Vamhi Label Cloud processes the following data, exclusively within the customer's Atlassian Forge/Jira environment:

• Jira label names and color/style metadata

• Jira issue-to-label associations

• Jira project identifiers (for scoping label libraries to the correct project)

No Personal Data Vamhi Label Cloud does not process, store, or transmit personal data, health data, financial data, or any other sensitive regulated data.

Data Storage

All data is stored exclusively within Atlassian's Forge storage infrastructure. No data is stored in Vamhi-managed databases or any system outside the customer's Atlassian environment.

Data Flows

Data flows only between the Forge app and the customer's Jira instance, entirely within Atlassian's infrastructure. No customer data is sent to external APIs, analytics services, or any third parties.

The one exception is frontend error reporting: unhandled JavaScript errors in the UI are captured by Sentry and transmitted to Sentry's platform for debugging purposes. Sentry is configured with the following privacy controls:

• User identification is disabled — no Jira user ID, name, email, or account details are attached to error events

• No Jira issue content, label names, or customer data is included in error payloads

• Only technical error data is captured: error message, stack trace, browser/environment context, and app version

• Sentry's data scrubbing rules are configured to strip any incidentally captured sensitive values

Data Retention & Deletion

Data retention is governed by the customer's Jira configuration and Atlassian's data retention policies. Customers control data deletion through Jira's native controls and the app's label management interface. Uninstalling the app removes the app's access to the customer's data.

Privacy by Design

• Minimum necessary data access — only required Jira API scopes are requested

• No user tracking, telemetry, or analytics data collection

• No data sharing with third parties

9. Business Continuity

Infrastructure Resilience

Vamhi Label Cloud's continuity relies on Atlassian Forge's built-in high-availability and disaster recovery infrastructure. Service availability SLAs are governed by Atlassian's Forge platform commitments.

App-Level Recovery

• All source code is stored in a version-controlled remote repository

• All deployment configurations are version-controlled and can be redeployed from source

• Previous versions of the app can be redeployed via Forge CLI in the event of a failed release

Known Gap — Formal DR Plan A formal documented disaster recovery plan covering RTO/RPO targets does not currently exist. Development of a formal DR plan is a roadmap item.

10. Human Resources Security

Onboarding

• All new team members are briefed on this security policy before being granted system access

• Secure coding practices, credential management, and phishing awareness are covered during onboarding

Security Awareness

Security awareness updates are provided at least annually or when significant new threats are identified.

Remote Working

• Public or unsecured Wi-Fi requires VPN use when accessing company systems

• Devices must have full-disk encryption enabled and OS updates kept current

• Screens must be locked when devices are unattended

Off boarding

All access is revoked within 24 hours of a team member's departure. Company devices are returned and any locally stored company or customer data is securely deleted.

11. Supply Chain Security

Third-Party Risk

• Third-party tools are evaluated for security posture before adoption

• Dependencies are kept up to date and scanned for known vulnerabilities

• Access granted to third-party services is scoped to the minimum necessary

12. Vulnerability Management

Detection

Vulnerabilities in app dependencies are detected via Snyk and Akidio SCA scanning, integrated into the development pipeline and running automatically on each code change.

Remediation SLAs

Tracking

All identified vulnerabilities are tracked in the development backlog with severity, affected component, and remediation status. Critical and high vulnerabilities are communicated to the Team Lead immediately upon detection.

13. Logging & Monitoring

Platform Logging

Atlassian Forge provides built-in logging and monitoring for all app deployments and API interactions. Logs are accessible to authorized Forge developers via the Forge developer console.

App-Level Logging

App-level diagnostic logging is implemented for debugging and operational monitoring. Logs do not contain personal data or sensitive customer information.

Frontend Error Monitoring (Sentry)

Sentry is integrated into the frontend to capture unhandled JavaScript errors in real time. The following controls govern its use:

• No user data: User identification is disabled. No Jira user ID, name, email, or account information is attached to error events

• No customer data: Label names, issue content, and project data are not included in error payloads

• Error-only scope: Only technical data is captured — error message, stack trace, browser/environment metadata, and app version

• Data scrubbing: Sentry's server-side scrubbing rules are configured to strip any incidentally captured sensitive values before storage

• Access control: Access to the Sentry project is restricted to authorized team members only, managed via Sentry's role-based access control

• Retention: Error events are retained in Sentry for 90 days, after which they are automatically deleted by Sentry's platform

Access to Logs

Access to Forge platform logs and Sentry error data is restricted to authorized team members and is reviewed as part of the annual access review.

Third-Party Sub-processorSentry (sentry.io) is used as a sub-processor for error monitoring. It receives technical error data only — no personal data or customer content. Sentry's privacy policy and data processing agreement are available at sentry.io/privacy.

14. Policy Compliance & Review

Compliance

All Vamhi team members are required to read, understand, and comply with this policy. Non-compliance is addressed by the Team Lead and may result in access revocation.

Exceptions

Any exception must be documented, approved by the Team Lead, and reviewed at the next annual policy review, with a risk assessment and compensating controls identified.

Review Triggers

This policy is reviewed annually. Ad-hoc reviews are triggered by a significant security incident, material changes to the app architecture, changes to Atlassian Marketplace requirements, or significant changes to applicable laws.

Version History

Applicable Standards

• CSA Cloud Controls Matrix (CCM) Lite v4.1.0

• Atlassian Marketplace Partner Agreement and Security Requirements

• Atlassian Forge Platform Security Guidelines

• GDPR (where applicable to EU customer data)