Saltar al contenido principal

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.


36. CEK-03.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Data Protection

Question ID: CEK-03.1

Question:

Are data protection at-rest and in-transit, and where applicable in use, provided using cryptographic libraries certified to approved standards?

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.


37. CEK-04.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Encryption Algorithm

Question ID: CEK-04.1

Question:

Are encryption algorithms following industry standards utilized for protecting data, based on the data classification and associated risks?

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.


38. CEK-05.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Encryption Change Management

Question ID: CEK-05.1

Question:

Are standard change management procedures established to review, approve, implement and communicate cryptography, encryption, and key management technology changes that accommodate internal and external sources?

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.


39. CEK-10.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Key Generation

Question ID: CEK-10.1

Question:

Are cryptographic keys generated using industry-accepted and approved cryptographic libraries that specify algorithm strength and random number generator specifications?

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.


40. CEK-12.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Key Rotation

Question ID: CEK-12.1

Question:

Are cryptographic keys rotated based on a cryptoperiod calculated while considering information disclosure risks and legal and regulatory requirements?

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.


41. CEK-13.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Key Revocation

Question ID: CEK-13.1

Question:

Are cryptographic keys revoked and removed before the end of the established cryptoperiod (when a key is compromised, or an entity is no longer part of the organization) per defined, implemented, and evaluated processes, procedures, and technical measures to include legal and regulatory requirement provisions?

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.


42. CEK-14.1

CCM domain: Cryptography, Encryption & Key Management

CCM control title: Key Destruction

Question ID: CEK-14.1

Question:

Are processes, procedures and technical measures to securely destroy cryptographic keys when they are no longer needed, defined, implemented, and evaluated, and include provisions for legal and regulatory requirements?

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.


43. DCS-04.1

CCM domain: Datacenter Security

CCM control title: Secure Area Policy and Procedures

Question ID: DCS-04.1

Question:

Are policies and procedures for maintaining a safe and secure working environment (in offices, rooms, and facilities) established, documented, approved, communicated, enforced, and maintained?

Answer:

Not applicable (inherited)

Implementation description:

We do not operate our own data centers. Production workloads for the Marketplace app run on Atlassian-managed infrastructure; physical and environmental controls are covered by Atlassian’s assurance program and public compliance materials.


44. DCS-04.2

CCM domain: Datacenter Security

CCM control title: Secure Area Policy and Procedures

Question ID: DCS-04.2

Question:

Are policies and procedures for maintaining safe, secure working environments (e.g., offices, rooms) reviewed and updated at least annually, or upon significant changes?

Answer:

Not applicable (inherited)

Implementation description:

We do not operate our own data centers. Production workloads for the Marketplace app run on Atlassian-managed infrastructure; physical and environmental controls are covered by Atlassian’s assurance program and public compliance materials.


45. DCS-06.1

CCM domain: Datacenter Security

CCM control title: Assets Classification

Question ID: DCS-06.1

Question:

Is the classification and documentation of physical and logical assets based on the organizational business risk?

Answer:

Not applicable (inherited)

Implementation description:

We do not operate our own data centers. Production workloads for the Marketplace app run on Atlassian-managed infrastructure; physical and environmental controls are covered by Atlassian’s assurance program and public compliance materials.


46. DCS-06.2

CCM domain: Datacenter Security

CCM control title: Assets Classification

Question ID: DCS-06.2

Question:

Are assets’ classifications reviewed and updated at least annually or upon significant changes?

Answer:

Not applicable (inherited)

Implementation description:

We do not operate our own data centers. Production workloads for the Marketplace app run on Atlassian-managed infrastructure; physical and environmental controls are covered by Atlassian’s assurance program and public compliance materials.


47. DCS-07.1

CCM domain: Datacenter Security

CCM control title: Assets Cataloguing and Tracking

Question ID: DCS-07.1

Question:

Are all relevant physical and logical assets at all CSP sites cataloged and tracked within a secured system?

Answer:

Not applicable (inherited)

Implementation description:

We do not operate our own data centers. Production workloads for the Marketplace app run on Atlassian-managed infrastructure; physical and environmental controls are covered by Atlassian’s assurance program and public compliance materials.


48. DCS-07.2

CCM domain: Datacenter Security

CCM control title: Assets Cataloguing and Tracking

Question ID: DCS-07.2

Question:

Is the catalogue reviewed and updated at least annually or upon significant changes?

Answer:

Not applicable (inherited)

Implementation description:

We do not operate our own data centers. Production workloads for the Marketplace app run on Atlassian-managed infrastructure; physical and environmental controls are covered by Atlassian’s assurance program and public compliance materials.


49. DSP-01.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Security and Privacy Policy and Procedures

Question ID: DSP-01.1

Question:

Are policies and procedures established, documented, approved, communicated, enforced, evaluated, and maintained for the preparation, classification, protection, and handling of data throughout its lifecycle according to all applicable laws and regulations, standards, and risk level?

Answer:

Yes

Implementation description:

We maintain a lightweight data inventory for the app: categories of data processed (largely Jira issue and project metadata needed for planning), purposes, and flows between the customer tenant and Forge. Details are aligned with our Privacy Policy and security documentation.


50. DSP-01.2

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Security and Privacy Policy and Procedures

Question ID: DSP-01.2

Question:

Are data security and privacy policies and procedures reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


51. DSP-03.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Inventory

Question ID: DSP-03.1

Question:

Is a data inventory created and maintained for sensitive, regulated and personal information (at a minimum)?

Answer:

Yes

Implementation description:

We maintain a lightweight data inventory for the app: categories of data processed (largely Jira issue and project metadata needed for planning), purposes, and flows between the customer tenant and Forge. Details are aligned with our Privacy Policy and security documentation.


52. DSP-03.2

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Inventory

Question ID: DSP-03.2

Question:

Is the inventory reviewed and updated at least annually or upon significant changes?

Answer:

Yes

Implementation description:

We maintain a lightweight data inventory for the app: categories of data processed (largely Jira issue and project metadata needed for planning), purposes, and flows between the customer tenant and Forge. Details are aligned with our Privacy Policy and security documentation.


53. DSP-04.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Classification

Question ID: DSP-04.1

Question:

Is data classified according to type and sensitivity levels?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


54. DSP-05.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Flow Documentation

Question ID: DSP-05.1

Question:

Is data flow documentation created to identify what data is processed and where it is stored and transmitted?

Answer:

Yes

Implementation description:

We maintain a lightweight data inventory for the app: categories of data processed (largely Jira issue and project metadata needed for planning), purposes, and flows between the customer tenant and Forge. Details are aligned with our Privacy Policy and security documentation.


55. DSP-05.2

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Flow Documentation

Question ID: DSP-05.2

Question:

Is data flow documentation reviewed at defined intervals, at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

We maintain a lightweight data inventory for the app: categories of data processed (largely Jira issue and project metadata needed for planning), purposes, and flows between the customer tenant and Forge. Details are aligned with our Privacy Policy and security documentation.


56. DSP-06.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Ownership and Stewardship

Question ID: DSP-06.1

Question:

Is the ownership and stewardship of all relevant personal and sensitive data documented?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


57. DSP-06.2

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Ownership and Stewardship

Question ID: DSP-06.2

Question:

Is data ownership and stewardship documentation reviewed at least annually?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


58. DSP-07.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Protection by Design and Default

Question ID: DSP-07.1

Question:

Are systems, products, and business practices based on security principles by design and per industry best practices?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


59. DSP-08.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Privacy by Design and Default

Question ID: DSP-08.1

Question:

Are systems, products, and business practices based on privacy principles by design and according to industry best practices?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


60. DSP-08.2

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Privacy by Design and Default

Question ID: DSP-08.2

Question:

Are systems' privacy settings configured by default and according to all applicable laws and regulations?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


61. DSP-10.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Sensitive Data Transfer

Question ID: DSP-10.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated to ensure any transfer of personal or sensitive data is protected from unauthorized access and only processed within scope (as permitted by respective laws and regulations)?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


62. DSP-11.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Personal Data Access, Reversal, Rectification and Deletion

Question ID: DSP-11.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated to enable data subjects to request access to, modify, or delete personal data (per applicable laws and regulations)?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


63. DSP-12.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Limitation of Purpose in Personal Data Processing

Question ID: DSP-12.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated to ensure personal data is processed (per applicable laws and regulations and for the purposes declared to the data subject)?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


64. DSP-13.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Personal Data Sub-processing

Question ID: DSP-13.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated for the transfer and sub-processing of personal data within the service supply chain (according to any applicable laws and regulations)?

Answer:

Yes

Implementation description:

Primary sub-processor for product operation is Atlassian (Forge / Jira Cloud). Additional processors (for example email or analytics used only on the marketing site) are listed or referenced in our Privacy Policy where applicable. We review agreements for security and data-processing terms.


65. DSP-14.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Disclosure of Data Sub-processors

Question ID: DSP-14.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated to disclose details to the data owner of any personal or sensitive data access by sub-processors before processing initiation?

Answer:

Yes

Implementation description:

Primary sub-processor for product operation is Atlassian (Forge / Jira Cloud). Additional processors (for example email or analytics used only on the marketing site) are listed or referenced in our Privacy Policy where applicable. We review agreements for security and data-processing terms.


66. DSP-16.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Retention and Deletion

Question ID: DSP-16.1

Question:

Do data retention, archiving, and deletion practices follow business requirements, applicable laws, and regulations?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


67. DSP-17.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Sensitive Data Protection

Question ID: DSP-17.1

Question:

Are processes, procedures, and technical measures defined and implemented to protect sensitive data throughout its lifecycle?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


68. DSP-19.1

CCM domain: Data Security and Privacy Lifecycle Management

CCM control title: Data Location

Question ID: DSP-19.1

Question:

Are processes, procedures, and technical measures defined and implemented to specify and document physical data locations, including locales where data is processed or backed up?

Answer:

Yes

Implementation description:

Security and privacy expectations are documented in our Information Security Policy and Privacy Policy. We apply data minimization for app features, review changes for privacy impact where relevant, and support customer rights requests as described in the Privacy Policy.


69. GRC-01.1

CCM domain: Governance, Risk and Compliance

CCM control title: Governance Program Policy and Procedures

Question ID: GRC-01.1

Question:

Are information governance program policies and procedures sponsored by organizational leadership established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

Governance is lightweight and appropriate to company size: named ownership for security topics, annual (or more frequent) policy review, risk discussions tied to releases and vendors, and alignment with Atlassian Marketplace obligations. See our published Information Security Policy.


70. GRC-01.2

CCM domain: Governance, Risk and Compliance

CCM control title: Governance Program Policy and Procedures

Question ID: GRC-01.2

Question:

Are the policies and procedures reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

Governance is lightweight and appropriate to company size: named ownership for security topics, annual (or more frequent) policy review, risk discussions tied to releases and vendors, and alignment with Atlassian Marketplace obligations. See our published Information Security Policy.


71. GRC-02.1

CCM domain: Governance, Risk and Compliance

CCM control title: Risk Management Program

Question ID: GRC-02.1

Question:

Is there an established and maintained formal, documented, and leadership-sponsored enterprise risk management (ERM) program that includes policies and procedures for identification, evaluation, ownership, treatment, and acceptance of risks?

Answer:

Yes

Implementation description:

Governance is lightweight and appropriate to company size: named ownership for security topics, annual (or more frequent) policy review, risk discussions tied to releases and vendors, and alignment with Atlassian Marketplace obligations. See our published Information Security Policy.


72. GRC-06.1

CCM domain: Governance, Risk and Compliance

CCM control title: Governance Responsibility Model

Question ID: GRC-06.1

Question:

Are roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs defined and documented?

Answer:

Yes

Implementation description:

Governance is lightweight and appropriate to company size: named ownership for security topics, annual (or more frequent) policy review, risk discussions tied to releases and vendors, and alignment with Atlassian Marketplace obligations. See our published Information Security Policy.


73. GRC-07.1

CCM domain: Governance, Risk and Compliance

CCM control title: Information System Regulatory Mapping

Question ID: GRC-07.1

Question:

Are all relevant standards, regulations, legal/contractual, and statutory requirements applicable to your organization identified and documented?

Answer:

Yes

Implementation description:

Governance is lightweight and appropriate to company size: named ownership for security topics, annual (or more frequent) policy review, risk discussions tied to releases and vendors, and alignment with Atlassian Marketplace obligations. See our published Information Security Policy.


74. GRC-07.2

CCM domain: Governance, Risk and Compliance

CCM control title: Information System Regulatory Mapping

Question ID: GRC-07.2

Question:

Are the identified requirements reviewed at least annually or upon significant changes?

Answer:

Yes

Implementation description:

Governance is lightweight and appropriate to company size: named ownership for security topics, annual (or more frequent) policy review, risk discussions tied to releases and vendors, and alignment with Atlassian Marketplace obligations. See our published Information Security Policy.


75. HRS-03.1

CCM domain: Human Resources

CCM control title: Clean Desk Policy and Procedures

Question ID: HRS-03.1

Question:

Are policies and procedures requiring unattended workspaces to conceal confidential data established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

We apply reasonable startup-scale HR security practices: confidentiality expectations for staff and contractors, security awareness on onboarding and when practices change, and remote-work guidance (acceptable use, device hygiene, MFA for corporate and production-related systems).


76. HRS-03.2

CCM domain: Human Resources

CCM control title: Clean Desk Policy and Procedures

Question ID: HRS-03.2

Question:

Are policies and procedures requiring unattended workspaces to conceal confidential data reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

We apply reasonable startup-scale HR security practices: confidentiality expectations for staff and contractors, security awareness on onboarding and when practices change, and remote-work guidance (acceptable use, device hygiene, MFA for corporate and production-related systems).


77. HRS-04.1

CCM domain: Human Resources

CCM control title: Remote and Home Working Policy and Procedures

Question ID: HRS-04.1

Question:

Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

We apply reasonable startup-scale HR security practices: confidentiality expectations for staff and contractors, security awareness on onboarding and when practices change, and remote-work guidance (acceptable use, device hygiene, MFA for corporate and production-related systems).


78. HRS-04.2

CCM domain: Human Resources

CCM control title: Remote and Home Working Policy and Procedures

Question ID: HRS-04.2

Question:

Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

We apply reasonable startup-scale HR security practices: confidentiality expectations for staff and contractors, security awareness on onboarding and when practices change, and remote-work guidance (acceptable use, device hygiene, MFA for corporate and production-related systems).


79. HRS-11.1

CCM domain: Human Resources

CCM control title: Security Awareness Training

Question ID: HRS-11.1

Question:

Is a security awareness training program for all employees of the organization established, documented, approved, communicated, applied, evaluated and maintained?

Answer:

Yes

Implementation description:

We apply reasonable startup-scale HR security practices: confidentiality expectations for staff and contractors, security awareness on onboarding and when practices change, and remote-work guidance (acceptable use, device hygiene, MFA for corporate and production-related systems).


80. HRS-11.2

CCM domain: Human Resources

CCM control title: Security Awareness Training

Question ID: HRS-11.2

Question:

Are regular security awareness training updates provided?

Answer:

Yes

Implementation description:

We apply reasonable startup-scale HR security practices: confidentiality expectations for staff and contractors, security awareness on onboarding and when practices change, and remote-work guidance (acceptable use, device hygiene, MFA for corporate and production-related systems).


81. IAM-01.1

CCM domain: Identity & Access Management

CCM control title: Identity and Access Management Policy and Procedures

Question ID: IAM-01.1

Question:

Are identity and access management policies and procedures established, documented, approved, communicated, implemented, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


82. IAM-01.2

CCM domain: Identity & Access Management

CCM control title: Identity and Access Management Policy and Procedures

Question ID: IAM-01.2

Question:

Are identity and access management policies and procedures reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


83. IAM-03.1

CCM domain: Identity & Access Management

CCM control title: Identity Inventory

Question ID: IAM-03.1

Question:

Is the inventory of identities managed, stored, and regularly reviewed, and is their level of access monitored?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


84. IAM-04.1

CCM domain: Identity & Access Management

CCM control title: Separation of Duties

Question ID: IAM-04.1

Question:

Is the separation of duties principle employed when implementing information system access?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


85. IAM-05.1

CCM domain: Identity & Access Management

CCM control title: Least Privilege

Question ID: IAM-05.1

Question:

Is the least privilege principle employed when implementing information system access?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


86. IAM-06.1

CCM domain: Identity & Access Management

CCM control title: Access Provisioning

Question ID: IAM-06.1

Question:

Is an identity access provisioning process defined and implemented which authorizes, records, and communicates data and assets access changes?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


87. IAM-07.1

CCM domain: Identity & Access Management

CCM control title: Access Changes and Revocation

Question ID: IAM-07.1

Question:

Is a process in place to de-provision or modify identity access in a timely manner?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


88. IAM-08.1

CCM domain: Identity & Access Management

CCM control title: Access Review

Question ID: IAM-08.1

Question:

Are reviews and revalidation of identity access for least privilege and separation of duties completed with a frequency commensurate with organizational risk tolerance, and at least annually or upon significant changes?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


89. IAM-09.1

CCM domain: Identity & Access Management

CCM control title: Segregation of Privileged Access Roles

Question ID: IAM-09.1

Question:

Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


90. IAM-10.1

CCM domain: Identity & Access Management

CCM control title: Management of Privileged Access Roles

Question ID: IAM-10.1

Question:

Is an access process defined and implemented to ensure privileged access roles and rights are granted for a limited period?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


91. IAM-10.2

CCM domain: Identity & Access Management

CCM control title: Management of Privileged Access Roles

Question ID: IAM-10.2

Question:

Are procedures implemented to prevent the accumulation of segregated privileged access?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


92. IAM-13.1

CCM domain: Identity & Access Management

CCM control title: Strong Authentication

Question ID: IAM-13.1

Question:

Are processes, procedures, and technical measures for authenticating access to systems, application, and data assets including multifactor authentication for a least-privileged user and sensitive data access defined, implemented, and evaluated?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


93. IAM-13.2

CCM domain: Identity & Access Management

CCM control title: Strong Authentication

Question ID: IAM-13.2

Question:

Are digital certificates or alternatives that achieve an equivalent security level for system identities adopted?

Answer:

Yes

Implementation description:

Production access to Forge, repositories, and cloud consoles is limited by role-based access, MFA, and individual accounts (no shared root credentials). We provision and revoke access on role changes. Customer tenant access is governed by the customer’s Jira/Atlassian identity; our app uses Atlassian-supported authorization models.


94. IPY-01.1

CCM domain: Interoperability & Portability

CCM control title: Interoperability and Portability Policy and Procedures

Question ID: IPY-01.1

Question:

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for communications between application interfaces (e.g., APIs)?

Answer:

Yes

Implementation description:

Public REST API surface area for the app (where offered) is documented for customers. We avoid undocumented “hidden” integration hooks for production use and version intentional changes.


95. IPY-01.2

CCM domain: Interoperability & Portability

CCM control title: Interoperability and Portability Policy and Procedures

Question ID: IPY-01.2

Question:

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information processing interoperability?

Answer:

Yes

Implementation description:

Public REST API surface area for the app (where offered) is documented for customers. We avoid undocumented “hidden” integration hooks for production use and version intentional changes.


96. IPY-01.3

CCM domain: Interoperability & Portability

CCM control title: Interoperability and Portability Policy and Procedures

Question ID: IPY-01.3

Question:

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for application development portability?

Answer:

Yes

Implementation description:

Public REST API surface area for the app (where offered) is documented for customers. We avoid undocumented “hidden” integration hooks for production use and version intentional changes.


97. IPY-01.4

CCM domain: Interoperability & Portability

CCM control title: Interoperability and Portability Policy and Procedures

Question ID: IPY-01.4

Question:

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information/data exchange, usage, portability, integrity, and persistence?

Answer:

Yes

Implementation description:

Public REST API surface area for the app (where offered) is documented for customers. We avoid undocumented “hidden” integration hooks for production use and version intentional changes.


98. IPY-01.5

CCM domain: Interoperability & Portability

CCM control title: Interoperability and Portability Policy and Procedures

Question ID: IPY-01.5

Question:

Are interoperability and portability policies and procedures reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

Public REST API surface area for the app (where offered) is documented for customers. We avoid undocumented “hidden” integration hooks for production use and version intentional changes.


99. I&S-03.1

CCM domain: Infrastructure Security

CCM control title: Network Security

Question ID: I&S-03.1

Question:

Are communications between environments, services, and applications monitored?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


100. I&S-03.2

CCM domain: Infrastructure Security

CCM control title: Network Security

Question ID: I&S-03.2

Question:

Are communications between environments, services, and applications encrypted?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


101. I&S-03.3

CCM domain: Infrastructure Security

CCM control title: Network Security

Question ID: I&S-03.3

Question:

Are communications between environments, services, and applications restricted to only authenticated and authorized connections, as justified by the business?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


102. I&S-03.4

CCM domain: Infrastructure Security

CCM control title: Network Security

Question ID: I&S-03.4

Question:

Are network configurations reviewed at least annually?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


103. I&S-03.5

CCM domain: Infrastructure Security

CCM control title: Network Security

Question ID: I&S-03.5

Question:

Are network configurations supported by the documented justification of all allowed services, protocols, ports, and compensating controls?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


104. I&S-04.1

CCM domain: Infrastructure Security

CCM control title: OS Hardening and Base Controls

Question ID: I&S-04.1

Question:

Is every host and guest OS, hypervisor, or infrastructure control plane hardened (according to their respective best practices) and supported by technical controls as part of a security baseline?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


105. I&S-06.1

CCM domain: Infrastructure Security

CCM control title: Segmentation and Segregation

Question ID: I&S-06.1

Question:

Are applications and infrastructures designed, developed, deployed, and configured such that service customer (tenant) access is appropriately segmented, segregated, monitored, and restricted?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


106. I&S-07.1

CCM domain: Infrastructure Security

CCM control title: Migration to Cloud Environments

Question ID: I&S-07.1

Question:

Are secure and encrypted communication channels including only up-to-date and approved protocols used when migrating servers, services, applications, or data to cloud environments?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


107. I&S-09.1

CCM domain: Infrastructure Security

CCM control title: Network Defense

Question ID: I&S-09.1

Question:

Are processes, procedures, and defense-in-depth techniques defined, implemented, and evaluated for protection, detection, and timely response to network-based attacks?

Answer:

Yes (platform)

Implementation description:

Network segmentation, perimeter defenses, and baseline hardening for the hosted runtime are operated by Atlassian. We configure app components according to Forge security guidance and restrict administrative access to our build/deploy paths.


108. LOG-01.1

CCM domain: Logging and Monitoring

CCM control title: Logging and Monitoring Policy and Procedures

Question ID: LOG-01.1

Question:

Are logging and monitoring policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

We use Forge/platform logging capabilities where applicable for security-relevant events in the app boundary. Access to operational logs is restricted to authorized engineering roles. We avoid logging sensitive personal content unless necessary and permitted.


109. LOG-01.2

CCM domain: Logging and Monitoring

CCM control title: Logging and Monitoring Policy and Procedures

Question ID: LOG-01.2

Question:

Are policies and procedures reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

We use Forge/platform logging capabilities where applicable for security-relevant events in the app boundary. Access to operational logs is restricted to authorized engineering roles. We avoid logging sensitive personal content unless necessary and permitted.


110. LOG-04.1

CCM domain: Logging and Monitoring

CCM control title: Audit Logs Access and Accountability

Question ID: LOG-04.1

Question:

Is audit log access restricted to authorized identities, and are records of that access maintained?

Answer:

Yes

Implementation description:

We use Forge/platform logging capabilities where applicable for security-relevant events in the app boundary. Access to operational logs is restricted to authorized engineering roles. We avoid logging sensitive personal content unless necessary and permitted.


111. LOG-05.1

CCM domain: Logging and Monitoring

CCM control title: Audit Logs Monitoring and Response

Question ID: LOG-05.1

Question:

Are capabilities implemented and maintained to correlate and monitor security audit logs for the detection of suspicious or anomalous activity that deviates from typical or expected patterns?

Answer:

Yes

Implementation description:

We use Forge/platform logging capabilities where applicable for security-relevant events in the app boundary. Access to operational logs is restricted to authorized engineering roles. We avoid logging sensitive personal content unless necessary and permitted.


112. LOG-05.2

CCM domain: Logging and Monitoring

CCM control title: Audit Logs Monitoring and Response

Question ID: LOG-05.2

Question:

Is a process established and followed to review and take appropriate and timely actions on detected anomalies?

Answer:

Yes

Implementation description:

We use Forge/platform logging capabilities where applicable for security-relevant events in the app boundary. Access to operational logs is restricted to authorized engineering roles. We avoid logging sensitive personal content unless necessary and permitted.


113. LOG-08.1

CCM domain: Logging and Monitoring

CCM control title: Audit Logs Sanitization

Question ID: LOG-08.1

Question:

Are technical measures defined, implemented, and evaluated to enable service customers to detect and scrub or tokenize sensitive data from logs, in order to prevent unauthorized exposure as per applicable laws and regulations?

Answer:

Yes

Implementation description:

We use Forge/platform logging capabilities where applicable for security-relevant events in the app boundary. Access to operational logs is restricted to authorized engineering roles. We avoid logging sensitive personal content unless necessary and permitted.


114. SEF-03.1

CCM domain: Security Incident Management, E-Discovery, & Cloud Forensics

CCM control title: Incident Response Plans

Question ID: SEF-03.1

Question:

Is a security incident response plan that includes a communication strategy for notifying relevant internal departments, impacted service customers, and other business-critical relationships (such as supply-chain) established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

We maintain a practical incident response playbook: detection, containment, eradication, recovery, and post-incident review. Customers are notified of personal data breaches where required by law and consistent with our Privacy Policy. We periodically walk through scenarios to keep contacts and steps current.


115. SEF-04.1

CCM domain: Security Incident Management, E-Discovery, & Cloud Forensics

CCM control title: Incident Response Testing

Question ID: SEF-04.1

Question:

Is a structured approach followed to evaluate the effectiveness of incident response plans at planned intervals or upon significant changes?

Answer:

Yes

Implementation description:

We maintain a practical incident response playbook: detection, containment, eradication, recovery, and post-incident review. Customers are notified of personal data breaches where required by law and consistent with our Privacy Policy. We periodically walk through scenarios to keep contacts and steps current.


116. SEF-07.1

CCM domain: Security Incident Management, E-Discovery, & Cloud Forensics

CCM control title: Incident Management and Response

Question ID: SEF-07.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated for timely and effective response to security incidents in accordance with incident categories and severity levels?

Answer:

Yes

Implementation description:

We maintain a practical incident response playbook: detection, containment, eradication, recovery, and post-incident review. Customers are notified of personal data breaches where required by law and consistent with our Privacy Policy. We periodically walk through scenarios to keep contacts and steps current.


117. SEF-07.2

CCM domain: Security Incident Management, E-Discovery, & Cloud Forensics

CCM control title: Incident Management and Response

Question ID: SEF-07.2

Question:

Are these processes and procedures reviewed, updated, and tested at least annually?

Answer:

Yes

Implementation description:

We maintain a practical incident response playbook: detection, containment, eradication, recovery, and post-incident review. Customers are notified of personal data breaches where required by law and consistent with our Privacy Policy. We periodically walk through scenarios to keep contacts and steps current.


118. SEF-08.1

CCM domain: Security Incident Management, E-Discovery, & Cloud Forensics

CCM control title: Security Breach Notification

Question ID: SEF-08.1

Question:

Are processes, procedures, and technical measures for security breach notifications defined and implemented?

Answer:

Yes

Implementation description:

We maintain a practical incident response playbook: detection, containment, eradication, recovery, and post-incident review. Customers are notified of personal data breaches where required by law and consistent with our Privacy Policy. We periodically walk through scenarios to keep contacts and steps current.


119. SEF-08.2

CCM domain: Security Incident Management, E-Discovery, & Cloud Forensics

CCM control title: Security Breach Notification

Question ID: SEF-08.2

Question:

Are material security breaches reported (including any relevant supply chain breaches) as per applicable SLAs, laws, and regulations?

Answer:

Yes

Implementation description:

We maintain a practical incident response playbook: detection, containment, eradication, recovery, and post-incident review. Customers are notified of personal data breaches where required by law and consistent with our Privacy Policy. We periodically walk through scenarios to keep contacts and steps current.


120. STA-01.1

CCM domain: Supply Chain Management, Transparency, and Accountability

CCM control title: Supply Chain Risk Management Policies and Procedures

Question ID: STA-01.1

Question:

Are policies and procedures for supply chain risk management established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

We inventory third-party packages and services, prefer supported dependencies, and review critical vendors (especially Atlassian and hosting-related services). We track known vulnerabilities and apply updates on a risk-based schedule.


121. STA-01.2

CCM domain: Supply Chain Management, Transparency, and Accountability

CCM control title: Supply Chain Risk Management Policies and Procedures

Question ID: STA-01.2

Question:

Are policies and procedures for supply chain risk management reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

We inventory third-party packages and services, prefer supported dependencies, and review critical vendors (especially Atlassian and hosting-related services). We track known vulnerabilities and apply updates on a risk-based schedule.


122. STA-03.1

CCM domain: Supply Chain Management, Transparency, and Accountability

CCM control title: SSRM Supply Chain

Question ID: STA-03.1

Question:

Is the SSRM applied, documented, implemented, and managed throughout the supply chain?

Answer:

Yes

Implementation description:

We inventory third-party packages and services, prefer supported dependencies, and review critical vendors (especially Atlassian and hosting-related services). We track known vulnerabilities and apply updates on a risk-based schedule.


123. STA-05.1

CCM domain: Supply Chain Management, Transparency, and Accountability

CCM control title: SSRM Control Ownership

Question ID: STA-05.1

Question:

Is the shared ownership and applicability of all CSA CCM controls delineated according to the SSRM?

Answer:

Yes

Implementation description:

We inventory third-party packages and services, prefer supported dependencies, and review critical vendors (especially Atlassian and hosting-related services). We track known vulnerabilities and apply updates on a risk-based schedule.


124. STA-08.1

CCM domain: Supply Chain Management, Transparency, and Accountability

CCM control title: Supply Chain Inventory

Question ID: STA-08.1

Question:

Is an inventory of all supply chain relationships developed and maintained?

Answer:

Yes

Implementation description:

We inventory third-party packages and services, prefer supported dependencies, and review critical vendors (especially Atlassian and hosting-related services). We track known vulnerabilities and apply updates on a risk-based schedule.


125. TVM-02.1

CCM domain: Threat & Vulnerability Management

CCM control title: Malware and Malicious Instructions Protection Policy and Procedures

Question ID: TVM-02.1

Question:

Are policies and procedures to protect against malware and malicious instructions established, documented, approved, communicated, applied, evaluated, and maintained?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


126. TVM-02.2

CCM domain: Threat & Vulnerability Management

CCM control title: Malware and Malicious Instructions Protection Policy and Procedures

Question ID: TVM-02.2

Question:

Are asset management and malware protection policies and procedures reviewed and updated at least annually, or upon significant changes?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


127. TVM-03.1

CCM domain: Threat & Vulnerability Management

CCM control title: Vulnerability Identification

Question ID: TVM-03.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated for vulnerability detection on organizationally managed assets at least monthly?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


128. TVM-05.1

CCM domain: Threat & Vulnerability Management

CCM control title: Detection Updates

Question ID: TVM-05.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated to update detection tools, threat signatures, and compromise indicators weekly (or more frequent) basis?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


129. TVM-08.1

CCM domain: Threat & Vulnerability Management

CCM control title: Vulnerability Remediation Schedule

Question ID: TVM-08.1

Question:

Are processes, procedures and technical measures defined, implemented and evaluated based on identified risks to support scheduled and emergency responses to vulnerability identification?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


130. TVM-10.1

CCM domain: Threat & Vulnerability Management

CCM control title: Threat Response

Question ID: TVM-10.1

Question:

Is a risk-based method used for the prioritization and mitigation of threats, leveraging an industry-recognized framework to guide threat decision-making and protection measures?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


131. TVM-11.1

CCM domain: Threat & Vulnerability Management

CCM control title: Vulnerability Management Reporting

Question ID: TVM-11.1

Question:

Is a process defined and implemented to track and report vulnerability identification and remediation activities that include stakeholder notification?

Answer:

Yes

Implementation description:

We use automated dependency scanning and security updates, monitor advisories, and remediate vulnerabilities based on severity. Malware risk on developer endpoints is reduced via OS updates, reputable tooling, and limited administrative rights where feasible.


132. UEM-02.1

CCM domain: Universal Endpoint Management

CCM control title: Application and Service Approval

Question ID: UEM-02.1

Question:

Is there a defined, documented, applicable and evaluated list containing approved services, applications, and the sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data?

Answer:

Yes

Implementation description:

Company laptops use full-disk encryption, automatic OS updates, screen lock, and host-based firewall where provided by the OS. Production access requires MFA.


133. UEM-04.1

CCM domain: Universal Endpoint Management

CCM control title: Endpoint Inventory

Question ID: UEM-04.1

Question:

Is an inventory of all endpoints used and maintained to store, access and process company data?

Answer:

Yes

Implementation description:

Company laptops use full-disk encryption, automatic OS updates, screen lock, and host-based firewall where provided by the OS. Production access requires MFA.


134. UEM-05.1

CCM domain: Universal Endpoint Management

CCM control title: Endpoint Management

Question ID: UEM-05.1

Question:

Are processes, procedures, and technical measures defined, implemented and evaluated, to enforce policies and controls for all endpoints permitted to access systems and/or store, transmit, or process organizational data?

Answer:

Yes

Implementation description:

Company laptops use full-disk encryption, automatic OS updates, screen lock, and host-based firewall where provided by the OS. Production access requires MFA.


135. UEM-06.1

CCM domain: Universal Endpoint Management

CCM control title: Automatic Lock Screen

Question ID: UEM-06.1

Question:

Are all relevant interactive-use endpoints configured to require an automatic lock screen?

Answer:

Yes

Implementation description:

Company laptops use full-disk encryption, automatic OS updates, screen lock, and host-based firewall where provided by the OS. Production access requires MFA.


136. UEM-09.1

CCM domain: Universal Endpoint Management

CCM control title: Anti-Malware Detection and Prevention

Question ID: UEM-09.1

Question:

Are anti-malware detection and prevention technology services configured on managed endpoints?

Answer:

Yes

Implementation description:

Company laptops use full-disk encryption, automatic OS updates, screen lock, and host-based firewall where provided by the OS. Production access requires MFA.


137. UEM-10.1

CCM domain: Universal Endpoint Management

CCM control title: Software Firewall

Question ID: UEM-10.1

Question:

Are software firewalls configured on managed endpoints?

Answer:

Yes

Implementation description:

Company laptops use full-disk encryption, automatic OS updates, screen lock, and host-based firewall where provided by the OS. Production access requires MFA.


138. UEM-13.1

CCM domain: Universal Endpoint Management

CCM control title: Remote Wipe

Question ID: UEM-13.1

Question:

Are processes, procedures, and technical measures defined, implemented, and evaluated to enable remote company data deletion on managed endpoint devices?

Answer:

Partial

Implementation description:

Company-issued or enrolled endpoints use standard protections (disk encryption, OS updates, screen lock). Full enterprise MDM with remote wipe of all company data is not uniformly deployed for every contractor device; we mitigate with contractual requirements, least access to production systems, and revocation of tokens/credentials when access must end.