How Cost Slasher handles data
Cost Slasher is a licence management application published by LeanZero SRL. This product-specific statement describes the application's data handling and configured retention, including its external AWS recovery service. It applies to the LeanZero-operated app and recovery service.
Updated 4 October 2026
Who is responsible
LeanZero SRL is registered in Romania: trade register J2025012835002, CUI 51336260, registered office Str. Toamnei 23 G, CAM. 1, Bragadiru, Ilfov, 077025. Contact office@leanzero.net for privacy questions. The customer organisation determines its licence policies and authorised account processing; LeanZero processes that app data on its behalf. LeanZero is responsible for the contact and support information people send directly to it.
The Cost Slasher Data Processing Addendum governs processing on an organisation's behalf. It covers documented instructions, confidentiality, security, subprocessors, assistance and return or deletion. The paid subscription, when available, is ordered through Atlassian Marketplace; LeanZero's recovery service does not collect payment-card details. See the beta terms for the commercial offer and earlier free invitations.
What the application uses
The application uses account identifiers, app and site identifiers, relevant group memberships and permissions, access states, observed app activity, licence policies, capacity allocations, time-away dates and timezones, and operation outcomes. These records support inactivity checks, managed licence release, explicit restoration and protected returns. Unknown observations remain unknown.
Organisation administrators define the apps and groups managed by the application and the app roles allowed to inspect or change them. Members can inspect their own access and bookings; other app roles are limited to their assigned scope. An Atlassian licence does not replace a space or project permission.
Atlassian sign-in and recovery
Recovery uses Atlassian OAuth with the User Identity read:me scope. The server requests the account identifier, display name and email address when Atlassian returns them. Identity is then checked separately from current eligibility and authority in the Forge installation. Signing in or opening a page does not grant a licence; restoration requires the user's explicit action.
Atlassian handles its sign-in screen. Cost Slasher does not ask for an Atlassian password. OAuth credentials and tokens are handled server-side. Normal recovery users grant only read:me; their sign-in does not request or store an offline refresh token. The gateway does not receive the organisation API key or bulk app activity history. An organisation credential, when configured, belongs to the Forge installation's secret storage.
A separate, publisher-only Atlassian authorisation uses read:me and offline_access for Atlassian's personal-data reporting service. Its refresh grant is encrypted in AWS Secrets Manager and retained until the publisher revokes or replaces it. This isolated grant reports retained account data and is not used for app access or organisation administration APIs.
The recovery service processes personal data outside Forge. Account identifiers and pseudonymous references remain personal data even when a display name or email is absent.
Where processing happens
Licence, capacity, policy, permission, activity and business audit records are stored in Forge for the primary Jira installation. Atlassian controls that storage location and its applicable data residency settings. A connected Confluence surface does not move those records to a separate Confluence installation.
The external recovery service uses AWS API Gateway and Lambda, encrypted DynamoDB session and registry storage, KMS and Secrets Manager in eu-west-1, Ireland. SES processes necessary notification recipients and message content in that region. Installation routing, organisation branding, pairing material, authority records, rate-limit budgets and minimal operation or delivery receipts support the external service.
CloudFront provides global transit and caching of static recovery files. Authentication and API responses are configured without caching. CloudFront's global network is separate from the Ireland origin; this is not a claim that every network transit remains in Ireland.
Sessions and retention
- Recovery sessions have an absolute eight-hour expiry, revocation checks and Secure, HttpOnly, SameSite cookies.
- Hashed account and organisation session-invalidation markers, and hashed erased-account write fences, expire after eight hours and five minutes. These safeguards prevent older identity records from restoring a revoked session or crossing a completed erasure.
- OAuth attempts expire after ten minutes; replay-protection nonce records expire after two minutes.
- Proxy-operation and minimal notification receipts expire after thirty days. Stored notification receipts contain no recipient address or message body.
- Encrypted failed-event storage retains events for up to fourteen days and can contain necessary notification delivery data. Runtime logs are configured for thirty days and HTTP status logs for fourteen days.
- Business audit retention defaults to 365 days. Usage retention defaults to 90 days. Administrators can configure the supported retention settings for their installation.
An encrypted external account inventory and record-reference table tracks account identifiers, the oldest personal-data retrieval timestamp and the associated session or proxy records. Inventory and references are bounded by the corresponding eight-hour session or thirty-day proxy retention, with a forty-eight-hour fallback expiry margin to preserve the erasure index while DynamoDB TTL deletion is asynchronous. The worker is scheduled every seventeen minutes to clean expired source records and inventory. It sends batches of at most ninety account identifiers and their oldest retrieval timestamps to Atlassian, using Atlassian's returned reporting cycle. A closed or updated account response starts deletion of that account's external sessions and proxy records; an unfinished deletion resumes under a write fence.
Expiry blocks use of an expired session immediately. Storage expiry is not an assurance of immediate physical deletion: DynamoDB TTL deletion is asynchronous. Encrypted backups and retained registry or handover records can remain beyond a record's active lifetime. Uninstalling the app or removing infrastructure does not automatically erase ownership evidence or settle unresolved operations.
Some registry, handover, authority, unresolved-operation and backup records have no automatic finite maximum after uninstall. This is a disclosure of the current storage lifecycle, not permission to retain personal data forever. Under the Data Processing Addendum, the organisation chooses return or deletion at the end of processing, except where applicable law requires retention. LeanZero coordinates that instruction and verifies completion; an unresolved operation or retained resource is not, by itself, a legal retention exception.
Audit and usage retention do not remove the operational records required to keep access, capacity, ownership and pending work consistent. Personal export and deletion requests therefore require a scoped review of operational minimums and applicable retention requirements.
Security and third parties
Recovery uses installation-bound signed requests, server-side identity verification, CSRF checks and scoped app permissions. Public gateway responses disallow framing. Application API access logs are configured to omit request URLs, queries, headers, cookies, recipients and bodies. Secrets and raw personal provider responses are excluded from business audit projections and exports.
The relevant service providers are Atlassian and Amazon Web Services. The recovery pages contain no analytics or advertising integrations, and this application does not use AI to process users' records. The separate LeanZero website has its own privacy and cookie policy; visiting a support or product website link is separate from using the app.
Support requests sent through the LeanZero portal are processed in Atlassian Jira Service Management. Email sent to office@leanzero.net is processed in LeanZero's Microsoft 365 mailbox. Those services can hold the sender's contact details, message and attachments. They are separate from Forge business records and the AWS recovery origin; the LeanZero company privacy policy describes support correspondence retention. Send only the information needed for the request and never send credentials.
The native app stores a small Saved requests journal in the browser's local storage. It contains a hash of the current account and installation scope, command and input digests, original request references and recorded states. It does not retain form inputs, credentials, display names, exports or server messages. Unresolved references have no automatic expiry, so clearing browser storage does not prove that a server request had no effect. The native app follows Atlassian's theme. Standalone recovery keeps the chosen light or dark theme in the browser's local storage as cost-slasher-theme. This preference stays in that browser until changed or cleared; it contains no account information and is not sent to the server. Recovery uses the necessary sign-in and session cookies described above; it has no tracking cookie.
Your requests and support
Members can request a copy of their own app records or record a deletion request through the app's privacy controls. Recording a request does not prove that an export or deletion has completed, and it does not delete an Atlassian account. The application preserves operational minimums until the authorised review and completion process resolves them. An accepted app request is not a verified deletion of every operational record, retained backup or Atlassian account. Privacy enquiries are handled under applicable data-protection requirements; contact LeanZero if an app request needs further review.
Contact LeanZero SRL through Cost Slasher support portal or office@leanzero.net for privacy questions, requests that cannot be made in the app, or information about retained backups and registry records. Contact your organisation's administrator for its licence policies and assigned permissions.
Beta availability and verification
A beta invitation or an enabled installation link is not evidence that every release or customer journey has been qualified. Ordinary zero-seat sign-in, denial-message coverage, provider effects, warnings, permissions, protected returns, routing and workload bounds require their own current acceptance. Automatic licence release stays off until the required recovery, warning, activity and capacity checks have been verified for the configured app. This statement does not claim Marketplace approval, a compliance certification, a service level agreement or acceptance for 20,000 users.