9 OCTOBER 2026 · VERSION 1.0

Partner Security Policy

This policy describes the security controls and security-report handling for Estimate Bench for Jira, provided by Jon Ander Irazusta Iribar, trading as ProfitSignal Labs. It covers the Forge app and the provider's handling of related support and security reports. The Privacy Notice separately explains personal-data processing and retention; the customer terms govern the service.

Report a security issue

Contact support@profitsignallabs.dev with the subject “Security — Estimate Bench”, or use our support portal. Include the affected app version, approximate time, impact and minimal reproduction steps using synthetic or redacted data. Do not send passwords, API tokens, full Jira exports or private customer records. If further evidence is needed, we will agree an appropriate channel and limit it to what the investigation requires.

Our general initial-response target is 24 hours. Support hours are Monday–Friday, 09:00–18:00 Europe/Madrid. Contractual response commitments remain 24 hours for requests Atlassian designates critical and five business days for other requests. These are response commitments, not guaranteed resolution times or a claim of continuously staffed monitoring. The provider is responsible for coordinating security reports and communications with Atlassian.

Application controls and access

• Estimate Bench uses Atlassian Forge native UI Kit and Jira reads under the current user's permissions (asUser). Its scope is read:jira-work. The app does not collect account passwords, API tokens or third-party credentials.
• There is no remote backend, web trigger, external runtime network destination, external AI service or Jira write operation.
• The backend limits JQL and pagination-token types and lengths, uses a fixed Jira search route with an explicit field allowlist and bounded page size, and does not expose user-controlled URLs or a generic API proxy. Browser inputs cannot select another user's identity.
• Dates and numeric analysis/scenario inputs are validated. Native UI renders text without raw HTML; CSV output escapes quotes and neutralizes formula-leading characters.

Data protection and related systems

The app reads issue identifiers, project and issue-type identifiers/names, status category, completion date, original estimate and logged time for the requested analysis. Processing is transient; there is no app-managed persistent review storage. Jira access and applicable visibility restrictions determine source data returned. Customer-controlled CSV copies and source Jira records remain under customer control. See the Privacy Notice for full details.

App code does not deliberately log review content or account identifiers. Atlassian infrastructure may generate operational logs under its policies. We investigate reported errors and security concerns; we do not claim continuously staffed monitoring, a dedicated security operations centre or custom production telemetry.

Atlassian operates the Forge runtime and Jira APIs. ProfitSignal Labs is responsible for application code, permission choices, configuration and release decisions. The documentation website uses Sites hosting; support uses Porkbun email and Atlassian Jira Service Management. The app does not automatically copy Jira records into these support channels. Investigations use minimal, redacted evidence, with access limited to the support or security purpose. Temporary contributor access used for testing is removed after the test. This policy does not claim platform certification of our app.

Vulnerability management and release checks

We use dependency vulnerability checks and review their results as part of release preparation. Findings and reports are assessed for affected versions, exploitability, permissions required and potential customer impact. Confirmed vulnerabilities are prioritized by severity and addressed under the applicable Atlassian Marketplace Security Bug Fix Policy. A dependency update or code correction is tested before release; a report is not considered resolved merely because a change was proposed.

Recovered source has been inspected and checked with dependency scanning. The production-dependency audit on 30 September 2026 reported no known vulnerabilities at that time. Bounded synthetic development checks covered completed/open issue handling, sample restrictions, export freshness and expiry, secondary-account denial, site separation and license responses. These development checks are not a certification of the submitted production artifact, and the recovered-source-to-production bundle match has not been cryptographically established. The historical audit is not a current scan or a guarantee that no vulnerability exists. No independent penetration test, certification, exhaustive permission matrix, continuous automated scanning or full load test is claimed.

Security incident handling

1. Assess and record: review the report, validate it safely, identify affected versions and installations where possible, and record the evidence and impact without collecting unnecessary customer content.
2. Contain: determine a proportionate mitigation with the affected customer and Atlassian when platform action is needed. Depending on the issue, this may involve restricting an affected function or advising a temporary workaround. Avoid destroying evidence or exposing further data.
3. Communicate: notify Atlassian and affected customers of confirmed security incidents or critical app vulnerabilities, using the applicable Marketplace incident process and contractual or legal notification requirements. Share known impact, available mitigation and the next update; clearly identify facts still under investigation.
4. Remediate and verify: correct the cause, test the fix and permission boundaries, release through the appropriate process and communicate the affected and corrected versions.
5. Review: document the cause, response and follow-up prevention measures. Keep investigation material limited to the security and legal need described in the Privacy Notice.

Reports should be coordinated privately while a vulnerability is assessed and corrected. This policy does not establish a paid bug-bounty program or authorize testing against other customers' data or systems.

Policy updates

We update this page when relevant security practices change. Material changes to processing or customer commitments are also reflected in the Privacy Notice or customer terms as applicable. Last updated: 9 October 2026.