CAIQLite Self Assessment
This page hosts the Consensus Assessments Initiative Questionnaire Lite (CAIQLite) v4.1.0 content used for Atlassian CCM Lite self-assessment. Source workbook: CAIQLitev4.1.0 (generated 2026-01-13).
Scope: Responses describe Be On Time practices for MSP Planner for Jira as a Marketplace app hosted on Atlassian Forge / Jira Cloud, including inherited controls from the platform where noted. This is a good-faith self-assessment, not a third-party audit report. For authoritative platform statements, see Atlassian Trust documentation.
For each control question: CCM domain, CCM control title, question ID, question, answer, implementation description.
Related: Information Security Policy.
1. A&A-02.1
CCM domain: Audit & Assurance
CCM control title: Independent Assessments
Question ID: A&A-02.1
Question:
Are independent audit and assurance assessments conducted according to relevant standards at least annually?
Answer:
Yes
Implementation description:
MSP Planner for Jira is distributed through the Atlassian Marketplace and runs on Atlassian Forge / Jira Cloud. Atlassian operates a broad assurance program for its platform and app ecosystem, including design- and build-time controls (for example pipeline checks and static analysis expectations for Marketplace apps), hosting-time security scanning and vulnerability management for deployed apps, and independent third-party audits of Atlassian services (see Atlassian’s Trust / security documentation). Be On Time monitors findings that apply to our application (for example from automated dependency and code scanning, security advisories, and Marketplace or partner security requirements), records them with owners and due dates, and implements corrective action plans with tracked remediation until closure and verification. Independent assurance on the underlying platform is performed by Atlassian’s third-party audit program on a recurring basis; we align our app security work with those expectations and with our own release testing.
2. A&A-03.1
CCM domain: Audit & Assurance
CCM control title: Risk Based Planning Assessment
Question ID: A&A-03.1
Question:
Are independent audit and assurance assessments performed according to risk-based plans and policies, and in response to significant changes or emerging risks?
Answer:
Yes
Implementation description:
MSP Planner for Jira is distributed through the Atlassian Marketplace and runs on Atlassian Forge / Jira Cloud. Atlassian operates a broad assurance program for its platform and app ecosystem, including design- and build-time controls (for example pipeline checks and static analysis expectations for Marketplace apps), hosting-time security scanning and vulnerability management for deployed apps, and independent third-party audits of Atlassian services (see Atlassian’s Trust / security documentation). Be On Time monitors findings that apply to our application (for example from automated dependency and code scanning, security advisories, and Marketplace or partner security requirements), records them with owners and due dates, and implements corrective action plans with tracked remediation until closure and verification. We prioritize remediation by risk (severity, exploitability, customer and data impact, and regulatory context) and re-plan when there are significant product or infrastructure changes.
3. A&A-04.1
CCM domain: Audit & Assurance
CCM control title: Requirements Compliance
Question ID: A&A-04.1
Question:
Is compliance verified regarding all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit?
Answer:
Yes
Implementation description:
Our scope includes applicable data protection law (including GDPR where relevant), the Atlassian Marketplace Partner Agreement and product terms, and customer contractual commitments. We map control expectations to our Information Security Policy (published on this site) and to operational procedures, and we review coverage when regulations or Marketplace requirements change.
4. A&A-06.1
CCM domain: Audit & Assurance
CCM control title: Remediation
Question ID: A&A-06.1
Question:
Is a risk-based corrective action plan to remediate audit findings established, documented, approved, communicated, applied, evaluated, and maintained?
Answer:
Yes
Implementation description:
We maintain a documented corrective-action process for security and compliance findings: intake/triage, owner assignment, remediation plan, implementation, verification (including re-test or scan where appropriate), and closure evidence. This applies to findings from automated scanning, dependency alerts, internal review, and Atlassian / Marketplace-related security expectations affecting our app.
5. A&A-06.2
CCM domain: Audit & Assurance
CCM control title: Remediation
Question ID: A&A-06.2
Question:
Is the remediation status of audit findings regularly reviewed and reported to relevant stakeholders?
Answer:
Yes
Implementation description:
Open remediation items are reviewed on a recurring cadence (at least monthly internally). Material items are escalated and status is communicated to stakeholders responsible for product delivery until closed.
6. AIS-02.1
CCM domain: Application & Interface Security
CCM control title: Application Security Baseline Requirements
Question ID: AIS-02.1
Question:
Are baseline requirements to secure applications established, documented, and maintained?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
7. AIS-04.1
CCM domain: Application & Interface Security
CCM control title: Secure Application Development Lifecycle
Question ID: AIS-04.1
Question:
Is a secure SDLC process defined and implemented for application requirements analysis, planning, design, development, testing, deployment, and operation per organizationally designed security requirements?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
8. AIS-06.1
CCM domain: Application & Interface Security
CCM control title: Secure Application Deployment
Question ID: AIS-06.1
Question:
Are strategies and capabilities established and implemented to deploy application code in a secure, standardized, and compliant manner?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
9. AIS-06.2
CCM domain: Application & Interface Security
CCM control title: Secure Application Deployment
Question ID: AIS-06.2
Question:
Is the deployment and integration of application code automated where possible?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
10. AIS-07.1
CCM domain: Application & Interface Security
CCM control title: Application Vulnerability Remediation
Question ID: AIS-07.1
Question:
Are application security vulnerabilities remediated following defined processes?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
11. AIS-07.2
CCM domain: Application & Interface Security
CCM control title: Application Vulnerability Remediation
Question ID: AIS-07.2
Question:
Is the remediation of application security vulnerabilities automated when possible?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
12. AIS-08.1
CCM domain: Application & Interface Security
CCM control title: API Security
Question ID: AIS-08.1
Question:
Are processes, procedures, and technical measures defined and implemented to secure APIs?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
13. AIS-08.2
CCM domain: Application & Interface Security
CCM control title: API Security
Question ID: AIS-08.2
Question:
Are reviews and updates for any improvements conducted at least annually, or upon significant changes?
Answer:
Yes
Implementation description:
We maintain documented baseline requirements for our TypeScript/React codebase: typed APIs, linting, peer code review, automated tests in CI, dependency updates, and secure handling of secrets and tokens. Apps are built and deployed through Atlassian Forge / Marketplace pipelines with repeatable builds.
14. BCR-01.1
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Business Continuity Management Policy and Procedures
Question ID: BCR-01.1
Question:
Are business continuity management and operational resilience policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
15. BCR-01.2
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Business Continuity Management Policy and Procedures
Question ID: BCR-01.2
Question:
Are the policies and procedures reviewed and updated at least annually, or upon significant changes?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
16. BCR-02.1
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Risk Assessment and Impact Analysis
Question ID: BCR-02.1
Question:
Are criteria for developing business continuity and operational resiliency strategies and capabilities established based on business disruption and risk impacts?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
17. BCR-02.2
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Risk Assessment and Impact Analysis
Question ID: BCR-02.2
Question:
Are the risk assessment and impact analysis reviewed and updated at least annually or upon significant changes?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
18. BCR-03.1
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Business Continuity Strategy
Question ID: BCR-03.1
Question:
Are strategies being established to reduce the impact of business disruptions, and are resiliency and recovery from business disruptions being improved?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
19. BCR-08.1
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Backup
Question ID: BCR-08.1
Question:
Are backups performed periodically?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
20. BCR-08.2
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Backup
Question ID: BCR-08.2
Question:
Is the confidentiality, integrity, and availability of the backup ensured?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
21. BCR-08.3
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Backup
Question ID: BCR-08.3
Question:
Can backups be restored appropriately for resiliency?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
22. BCR-09.1
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Disaster Response Plan
Question ID: BCR-09.1
Question:
Is a disaster response plan established, documented, approved, applied, evaluated, and maintained to ensure recovery from natural and man-made disasters?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
23. BCR-09.2
CCM domain: Business Continuity Management and Operational Resilience
CCM control title: Disaster Response Plan
Question ID: BCR-09.2
Question:
Is the disaster response plan updated at least annually, and when significant changes occur?
Answer:
Yes
Implementation description:
Service continuity for the hosted product relies on Atlassian Forge / Jira Cloud availability and published SLAs. We maintain internal continuity basics: on-call ownership for incidents, documented recovery steps for our components, backups of source code and configuration in Git, and communication paths to customers via support channels.
24. CCC-01.1
CCM domain: Change Control and Configuration Management
CCM control title: Change Management Policy and Procedures
Question ID: CCC-01.1
Question:
Are policies and procedures for managing the risks associated with applying changes to assets owned, controlled, or used by the organization established, documented, approved, communicated, applied, evaluated, and maintained?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
25. CCC-01.2
CCM domain: Change Control and Configuration Management
CCM control title: Change Management Policy and Procedures
Question ID: CCC-01.2
Question:
Are the policies and procedures reviewed and updated at least annually, or upon significant changes?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
26. CCC-02.1
CCM domain: Change Control and Configuration Management
CCM control title: Quality Testing
Question ID: CCC-02.1
Question:
Is a defined quality change control, approval and testing process, incorporating baselines, testing, and release standards, established, maintained and implemented?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
27. CCC-04.1
CCM domain: Change Control and Configuration Management
CCM control title: Unauthorized Change Protection
Question ID: CCC-04.1
Question:
Is a procedure to authorize the addition, removal, update, and management of assets owned, controlled, or used by the organization, implemented and enforced?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
28. CCC-05.1
CCM domain: Change Control and Configuration Management
CCM control title: Change Agreements
Question ID: CCC-05.1
Question:
Are provisions to limit changes directly impacting service customer-owned environments (tenants) to explicitly authorized requests included within service level agreements?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
29. CCC-06.1
CCM domain: Change Control and Configuration Management
CCM control title: Change Management Baseline
Question ID: CCC-06.1
Question:
Are change management and configuration baselines established, documented and implemented for all relevant authorized changes on organizational assets?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
30. CCC-06.2
CCM domain: Change Control and Configuration Management
CCM control title: Change Management Baseline
Question ID: CCC-06.2
Question:
Are the baselines reviewed and updated at least annually or upon significant changes?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
31. CCC-07.1
CCM domain: Change Control and Configuration Management
CCM control title: Detection of Baseline Deviation
Question ID: CCC-07.1
Question:
Are detection measures implemented with proactive notification if changes deviate from established baselines?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
32. CCC-09.1
CCM domain: Change Control and Configuration Management
CCM control title: Change Restoration
Question ID: CCC-09.1
Question:
Is a process to proactively roll back changes to a previously known "good state" defined and implemented in case of errors or security concerns?
Answer:
Yes
Implementation description:
Changes flow through version control with pull requests, review, and automated checks where configured. Production releases follow a defined release process. Unauthorized changes to our repositories and build accounts are mitigated via MFA, least-privilege access, and provider-side controls (Forge/Git hosting).
33. CEK-01.1
CCM domain: Cryptography, Encryption & Key Management
CCM control title: Encryption and Key Management Policy and Procedures
Question ID: CEK-01.1
Question:
Are cryptography, encryption, and key management policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?
Answer:
Yes
Implementation description:
Cryptographic controls for data in transit and at rest in the Forge/Jira Cloud runtime are provided by Atlassian and underlying cloud infrastructure per Atlassian documentation. We follow Forge secret storage practices for app credentials and avoid embedding secrets in source code.
34. CEK-01.2
CCM domain: Cryptography, Encryption & Key Management
CCM control title: Encryption and Key Management Policy and Procedures
Question ID: CEK-01.2
Question:
Are cryptography, encryption, and key management policies and procedures reviewed and updated at least annually, upon significant changes?
Answer:
Yes
Implementation description:
Cryptographic controls for data in transit and at rest in the Forge/Jira Cloud runtime are provided by Atlassian and underlying cloud infrastructure per Atlassian documentation. We follow Forge secret storage practices for app credentials and avoid embedding secrets in source code.
35. CEK-02.1
CCM domain: Cryptography, Encryption & Key Management
CCM control title: CEK Roles and Responsibilities
Question ID: CEK-02.1
Question:
Are cryptography, encryption, and key management roles and responsibilities defined and implemented?
Answer:
Yes
Implementation description:
Cryptographic controls for data in transit and at rest in the Forge/Jira Cloud runtime are provided by Atlassian and underlying cloud infrastructure per Atlassian documentation. We follow Forge secret storage practices for app credentials and avoid embedding secrets in source code.