Frank handles sensitive employee information, so data security matters. The architecture ensures your data stays within your control and never leaves the Atlassian platform.
Built on Forge
Frank is built entirely on Atlassian Forge, Atlassian's cloud development platform. This has important security implications:
-
No external servers: Frank's code runs on Atlassian's infrastructure, not on third-party servers.
-
No data transfer: Employee data never leaves your Atlassian instance. There are no external API calls that transmit your data elsewhere.
-
Atlassian's security: Frank inherits Atlassian's security certifications, compliance, and infrastructure protections.
When you use Frank, your data stays exactly where it already is — in Jira and Confluence.
Where data is stored
Frank doesn't create its own database. Instead, it uses native Atlassian storage:
-
Employee records: Stored as Jira issues in the employee project
-
Documents and files: Stored as Jira attachments
-
Employee folders and onboarding documents: Stored in Confluence pages
-
Configuration: Stored in Forge's secure storage within your Atlassian instance
This means your data follows your existing Atlassian data residency settings. If you've configured data residency for compliance reasons (keeping data in specific geographic regions), Frank respects those configurations.
Data retention
Data retention follows your Jira and Confluence retention policies. Frank doesn't impose its own retention rules.
When an employee becomes an alumni, you decide what happens to their record. You can:
-
Keep the record for historical reference
-
Archive it according to your organization's policies
-
Delete it when no longer needed
The same applies to documents in Confluence — they follow your space's retention and archival settings.
Audit trails
Jira and Confluence maintain audit logs that track who views and edits content. These logs capture access to employee records and documents, providing the audit trail you need for compliance and security reviews.