Partner security policy

Scope

This policy covers QuotaLedger for Jira Service Management, its Forge functions, Forge SQL storage, queues, scheduled jobs, Custom UI resources, operational processes, and the public trust center. It applies to the production Marketplace release and to TechnofyStore personnel with product responsibilities.

Architecture and data boundaries

QuotaLedger runs entirely on Atlassian Forge. Application compute and customer data storage use Forge and Forge SQL, isolated per installation. The production manifest declares no remote backend, external analytics, advertising, session replay, or data-egress domain.

The app stores only the Jira and JSM identifiers, quantities, configuration, timestamps, audit reasons, and technical correlation data required for entitlement accounting and reconciliation. It does not intentionally persist issue descriptions, comments, attachments, customer messages, worklog descriptions, credentials, or payment-card data.

Identity and access control

• Authentication is provided by Atlassian; QuotaLedger does not maintain separate customer passwords.
• Administrative functions require Jira administrator permission.
• Project functions combine Jira project access with configured group-backed Manager, Finance, or Auditor roles.
• Issue access is rechecked through Jira as the current user.
• Portal results require an authenticated request, explicit contract coverage, and current membership in the bound JSM organization.
• Failed or ambiguous portal authorization returns a neutral no-coverage response without disclosing internal identifiers or balances.

Application and ledger integrity

Controls include server-side authorization, prepared and parameterized SQL, bounded validation schemas, idempotent event keys, forward-only database migrations, least-privilege Forge scopes, dependency and test gates, and redacted diagnostics. Ledger movements are append-only: corrections create auditable reversals or adjustments rather than silently rewriting historical entries. Derived balance projections can be rebuilt from authoritative ledger evidence.

Development and vulnerability management

Changes are reviewed through automated linting, type checks, unit and integration tests, migration checks, and production deployment gates. Dependencies and the Forge manifest are reviewed for known risk and unnecessary access. Confirmed vulnerabilities are prioritized by exploitability, affected data, tenant isolation, and customer impact; remediation and communication follow the incident process below.

Monitoring, continuity, and incident response

QuotaLedger uses correlation identifiers, reconciliation jobs, integrity checks, migration status, and Forge operational logs to identify failures without placing customer content in ordinary diagnostic bundles. Security incidents are contained, investigated, remediated, and documented. Affected customers and Atlassian are notified when required by contract, law, or Marketplace policy. Recovery relies on the append-only ledger, deterministic replay, and rebuildable projections.

Responsible vulnerability reporting

Report suspected vulnerabilities privately to support@callsiq.com or through the TechnofyStore JSM support portal. Select or state that the request is a security report and provide the affected app version, Atlassian site URL, reproduction steps, impact, and minimal redacted evidence.

Do not include credentials, access tokens, personal data, issue bodies, worklog descriptions, or full exports. Do not publicly disclose an unremediated vulnerability or access data beyond what is necessary to demonstrate the issue. TechnofyStore will acknowledge and triage good-faith reports through the private support process.

Policy maintenance

This policy is reviewed after material architectural or security-process changes and at least annually. Material changes are published at this stable URL. Privacy, retention, and customer-request details are described in the privacy policy; support targets are described in the support policy.