Purpose and scope
Purpose. This document is our umbrella information security policy: it sets management direction for protecting confidentiality, integrity, and availability of information we process, and it aligns day-to-day practices for a small, product-focused organization.
Scope. The policy applies to all personnel with access to Be On Time systems or data (employees and contractors), and to all company-managed accounts, code repositories, build systems, and production-adjacent services used to deliver our products and operate this portal. Customer-operated environments (for example, a customer’s own Jira tenant configuration) remain the customer’s responsibility except where our apps explicitly process data on their behalf.
Shared responsibility for Marketplace apps. Where products run on Atlassian Forge / Jira Cloud, the security of the underlying platform and physical infrastructure is provided by Atlassian and described in Atlassian’s Trust and compliance materials. We remain responsible for secure application design, dependency and release practices, secrets handling in our code, and how we operate our vendor and support access.
Roles and responsibilities
- Leadership approves this policy, ensures resources are available for security work, and treats material risks as business decisions.
- Engineering ownership implements secure development, access controls for repositories and cloud consoles, patching and vulnerability response for components we control, and logging/monitoring appropriate to our scale.
- Everyone follows access rules, uses MFA where required, reports suspected incidents promptly, and protects credentials.
For a compact team, named individuals may combine roles; responsibilities still apply and are communicated internally.
Security principles
- Least privilege for systems and data needed to perform a role.
- Defense in depth using platform capabilities, secure defaults, reviews, and monitoring layered as appropriate.
- Data minimization: collect and retain only what is needed for documented purposes (see also our Privacy Policy).
- Transparency: maintain customer-facing security and privacy documentation proportionate to risk and regulatory expectations.
Information and risk
We maintain a lightweight inventory of information types we process in products (for example Jira-related metadata and identifiers required for planning features), where they flow, and which processors are involved. We review this when launching material new features or integrations.
Risk management is practical rather than bureaucratic: we identify significant risks during design and when incidents or near-misses occur, record decisions and mitigations, and revisit them periodically or when the threat landscape changes materially.
Access control
- Individual accounts and MFA for production-related and source-control systems; no shared “break-glass” credentials without documented exception.
- Joiner–mover–leaver: access is granted on need, reviewed when roles change, and revoked promptly on exit.
- Secrets are not committed to repositories; we use provider-supported secret storage (for example Forge app secrets) and rotate when compromise is suspected.
Development and change management
- Changes go through version control with peer review where feasible and automated checks where configured.
- We use typed code, linting, dependency monitoring, and testing appropriate to the change before production release.
- We track security findings (for example from scans or reviews) to closure with owners and dates, including corrective actions after significant incidents or assessment outputs.
Vendors and subprocessors
We rely on a small set of critical vendors (notably Atlassian for Forge/Jira hosting and related developer tooling). We select vendors with credible security posture, use written agreements where available, and review security expectations when services are material to customer data or availability.
Subprocessors relevant to personal data on the website or products are described or linked in our Privacy Policy.
Incidents and business continuity
We maintain a short incident response playbook covering detection, containment, communication, recovery, and post-incident review. Personal data breaches are handled in line with applicable law and our Privacy Policy.
For product availability, we align with platform SLAs where the app runs on Atlassian-managed infrastructure, and we maintain internal continuity basics (source availability, documented recovery steps, support channels).
Awareness and acceptable use
Personnel receive security onboarding and refreshes when practices change. Acceptable use covers phishing awareness, safe handling of customer data, and reporting suspicious activity to the responsible owner without delay.
Policy review
This policy is reviewed at least annually, and after significant organizational changes, major incidents, or new regulatory obligations. Version history is reflected in the “Last updated” line above; substantive changes will be noted in release notes or an equivalent customer-visible channel where appropriate.
Contact
Security questions: use the Support contact form and mention “security” in the message.