Nicolás De León (Vortex Labs) Atlassian Partner

Yes, that works. WAS is one of the operators the JQL docs list for Status, so it runs as written. One thing to know before you trust it. It returns every completed change that was declined at some point, including the ones that went back through review and were then properly authorized, and those aren't findings. JQL can't…

Thanks Marcin. Sampling is where linking the removals pays off: whichever items the auditor picks, each one already carries its own date and approver. Glad this turned into a useful thread.

Agreed, Marcin. The removals are what an auditor actually tests, so keeping them next to the frozen list closes the loop. One practical addition on the Jira side. If each removal is its own work item linked to the review, the "when and why" comes with a timestamp and an approver already attached, and next quarter's review…

Thanks Marcin, that's a fair gap and a good place to draw the line. The guide only covers evidence that lives in work items, and access reviews and configuration changes don't. One thing I'd carry over from the work-item side is that the snapshot needs the same controls as any other evidence. When an access review is…

Gabriela, the "Changes that never reach Authorize" part is the one an ISO 27001 auditor will find for you if you don't find it first. For Annex A 8.32 they usually pull a sample of completed changes and ask to see the approval on each one, so the buttons that skip Authorize turn into audit findings, not just loose ends.…

Mia, question 2 is the one an admin can check without taking the vendor's word for it. In Atlassian Administration, open Data management, then Data residency, and select View details on the product. Installed apps are sorted into Pinned, Eligible, Not eligible and No action available. Two things I'd add from the vendor…

Thanks Sami. One view from the vendor side, since "properties can be the app's state" is the line admins will act on. A Forge app has two places to keep its own data. Issue properties live on the work item, so they count toward the 500 MB. Each value is capped at 32 KB, but the number of properties per item has no cap, and…

Thanks for the write-up, Marion. Sascha's point about continuous updates has a practical side for Marketplace apps that validation teams can use. On Forge apps, updates come in two kinds. Minor versions reach every site automatically, with no admin consent. Major versions wait until a site admin approves them, and Forge…

Thanks Sami, and thanks for the credit. One refinement before it goes on the checklist. "Anything beyond Atlassian's own domains" has a legitimate exception. Runs on Atlassian allows egress for analytics, as long as no in-scope End-User Data leaves the app. In the manifest that is an egress entry marked category: analytics…

Thanks Sami, the intake form line is the one I'm taking back to my own checklist. One note from the vendor side, since we ship a Forge app that qualifies for Runs on Atlassian. The rule is stricter than most admins expect. It isn't only about where the vendor's backend runs. A web font pulled from a CDN, an error tracker,…

One that cost us an hour while building a Forge app for Jira. Issue type names are localized, and the REST API takes them by name. Our test site runs in Spanish, so creating an issue as "Task" failed with "Especifica un tipo de incidencia válido" (specify a valid issue type). On that site the type is called "Tarea". The…