Permissions, Privacy, and Security
Simple Risk Register is built on Atlassian Forge and runs entirely within Atlassian Cloud infrastructure. This page explains what data is accessed, how it’s stored, and the security model.
Atlassian Forge platform
Simple Risk Register runs on Atlassian Forge, Atlassian’s serverless platform for app development. This means:
- No external servers: All app code runs in Atlassian’s infrastructure
- No external databases: Data is stored in Forge Storage
- Built-in security: Forge provides authentication and authorization
- Automatic scaling: Handles traffic without infrastructure management
Requested permissions (scopes)
The app requests these OAuth scopes:
| Scope | Purpose | What it allows |
|---|---|---|
read:jira-work | Read Jira data | Access project info, issues, and issue metadata for linking |
write:jira-work | Write Jira data | Support issue integration in Jira UI |
read:jira-user | Read user data | Resolve user details for risk owners and history |
storage:app | App storage | Store risk records in Forge Key-Value Storage |
Why these scopes are needed
- read:jira-work: Required to search and display issues for linking to risks
- write:jira-work: Required for issue panel integration in Jira UI
- read:jira-user: Required to display user names and avatars for risk owners
- storage:app: Required to persist risk data in Forge Storage
What data is stored
Risk records
For each risk, the app stores:
| Data | Description | Retention |
|---|---|---|
| Title | Risk name | Until risk is deleted |
| Description | Detailed explanation | Until risk is deleted |
| Probability | 1-5 value | Until risk is deleted |
| Impact | 1-5 value | Until risk is deleted |
| Status | Open/Mitigated/Closed | Until risk is deleted |
| Owner | Jira account ID | Until risk is deleted |
| Mitigation Plan | Mitigation text | Until risk is deleted |
| Created timestamp | ISO timestamp | Until risk is deleted |
| Created by | Jira account ID | Until risk is deleted |
| Updated timestamp | ISO timestamp | Until risk is deleted |
| Linked Issues | Issue keys and metadata | Until unlinked or risk deleted |
| History | Change log entries | Until risk is deleted |
Linked issue metadata
When you link a Jira issue to a risk, the app stores:
- Issue key (e.g., “PROJ-123”)
- Issue summary
- Issue status
- Issue type
- Issue URL
- Issue priority (if available)
- Issue assignee (if assigned)
History entries
Each change to a risk creates a history entry:
- Timestamp
- User account ID who made the change
- Action type (created, updated, linked_issue, unlinked_issue)
- Field changed (for updates)
- Old value and new value
Data location and isolation
Where data is stored
- Storage: Forge Key-Value Storage (KVS)
- Location: Atlassian Cloud infrastructure
- Region: Same region as your Jira instance
Data isolation
| Isolation Level | Description |
|---|---|
| Tenant isolation | Data is isolated by Jira site (tenant) |
| Project isolation | Data is scoped to individual projects |
| No cross-project access | Risks in one project cannot be accessed from another |
Data ownership
- Risk data belongs to your organization
- Small Batch Apps (the developer) does not access your risk data
- Data remains in your Atlassian tenant
Network and external access
API calls
The app makes API calls only to:
| Destination | Purpose |
|---|---|
| Jira REST API | Read project info, issues, user details |
| Forge Platform APIs | Storage, context, app configuration |
No external services
The app does NOT:
- Send data to third-party servers
- Use external analytics services
- Connect to external databases
- Make calls outside Atlassian infrastructure
No cookies or tracking
- The app does not set cookies
- The app does not use tracking pixels
- The app does not collect usage analytics
User access model
Within a project
Any user who can access a Jira project can:
- View all risks in that project
- Create new risks
- Edit any risk
- Delete any risk
- Link/unlink issues
Note: There is no role-based access control within the app. Access is controlled by Jira project permissions.
Cross-project access
- Users cannot access risks from projects they don’t have access to
- Risks are never shared between projects
- Each project has its own independent risk register
Data retention and deletion
Deleting individual risks
- When you delete a risk, it is permanently removed
- Deletion cannot be undone
- History is deleted along with the risk
Uninstalling the app
When the app is uninstalled:
- Forge Storage data is retained per Atlassian’s retention policy
- Data may be permanently deleted after a grace period
- Reinstalling the app does not restore deleted data
Data portability
- Export your risks to CSV before uninstalling
- CSV export contains all risk data for backup
Compliance considerations
Data residency
- Data is stored in the same region as your Jira Cloud instance
- Check your Atlassian organization settings for data residency details
GDPR and privacy
- The app processes personal data (user names, account IDs) for risk owners
- This data is already in Jira and is only displayed, not duplicated elsewhere
- Deleting a risk removes references to users in that risk’s data
Audit trail
- The history feature provides an audit trail of all changes
- History includes who made changes and when
- History is retained until the risk is deleted
Security best practices
For your organization:
- Review permissions: Understand what data the app can access
- Limit project access: Use Jira permissions to control who can manage risks
- Regular exports: Export periodically for backup and compliance
- Review linked issues: Periodically verify linked issues are still relevant
Privacy policy
For full details on data handling, see our Privacy Policy.
Contact for security concerns
If you have security concerns or questions:
- Support portal: https://small-batch.atlassian.net/servicedesk/customer/portal/34
- Security email: [email protected]