Vendor: Yamuno Assessment Date: April 4, 2026 Standard: Consensus Assessments Initiative Questionnaire Lite (CAIQ Lite) v4.1.0, based on Cloud Controls Matrix (CCM) v4.1 Contact: [email protected] Website: yamuno.com
| Metric | Count |
|---|---|
| Total Questions | 138 |
| Yes | 119 |
| N/A | 19 |
| No | 0 |
Architecture Note: All Yamuno applications are built on the Atlassian Forge platform — a serverless, sandboxed runtime managed entirely by Atlassian. Yamuno does not operate external servers, databases, networking infrastructure, or storage. Where a control is managed by the platform provider (Atlassian), this is noted accordingly.
SSRM Ownership Legend:
The official CAIQ Lite spreadsheet (XLSX) is available for download: yamuno-caiq-lite-v4.xlsx
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| A&A-02.1 | Are independent audit and assurance assessments conducted according to relevant standards at least annually? | Yes | Shared CSP and third party | We conduct periodic internal security reviews. Our apps run on Atlassian Forge, which undergoes independent SOC 2 Type II and ISO 27001 audits annually. We are pursuing independent SOC 2 Type II certification for Yamuno. |
| A&A-03.1 | Are independent audit and assurance assessments performed according to risk-based plans and policies, and in response to significant changes or emerging risks? | Yes | Shared CSP and third party | Security reviews are triggered by significant changes (new app releases, dependency updates, architecture changes) and on a periodic basis. Atlassian performs risk-based assessments on the Forge platform. |
| A&A-04.1 | Is compliance verified regarding all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit? | Yes | Shared CSP and third party | We verify compliance with the Atlassian Marketplace Partner Agreement, GDPR, CCPA, and applicable export control regulations. Atlassian verifies platform-level compliance. |
| A&A-06.1 | Is a risk-based corrective action plan to remediate audit findings established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | CSP-owned | Vulnerability findings are tracked and remediated per severity SLAs: Critical 24h, High 7d, Medium 30d, Low 90d. Security patches are prioritized above feature development for Critical and High issues. |
| A&A-06.2 | Is the remediation status of audit findings regularly reviewed and reported to relevant stakeholders? | Yes | CSP-owned | Remediation status is tracked in our issue management system and reviewed regularly. Dependency vulnerability alerts are monitored continuously via automated scanning. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| AIS-02.1 | Are baseline requirements to secure applications established, documented, and maintained? | Yes | CSP-owned | We maintain baseline security requirements for all apps including: mandatory code review, dependency scanning, least-privilege Forge permissions, no external data transmission, and no storage of secrets in source code. |
| AIS-04.1 | Is a secure SDLC process defined and implemented for application requirements analysis, planning, design, development, testing, deployment, and operation per organizationally designed security requirements? | Yes | CSP-owned | Our SDLC includes: security requirements at feature inception, mandatory peer code review for all changes, automated dependency scanning (npm audit), staged deployment via Forge CLI, and automated testing. |
| AIS-06.1 | Are strategies and capabilities established and implemented to deploy application code in a secure, standardized, and compliant manner? | Yes | Shared CSP and third party | Application code is deployed through Atlassian Forge's managed deployment pipeline, which enforces sandboxing, permission scoping, and environment isolation. Deployments follow a staged rollout process. |
| AIS-06.2 | Is the deployment and integration of application code automated where possible? | Yes | Shared CSP and third party | Deployments are automated through the Forge CLI pipeline with automated testing. Manual approval is required for production releases. |
| AIS-07.1 | Are application security vulnerabilities remediated following defined processes? | Yes | CSP-owned | Application vulnerabilities are remediated per our severity SLAs. Dependency vulnerabilities are detected via automated npm audit in CI and resolved promptly. |
| AIS-07.2 | Is the remediation of application security vulnerabilities automated when possible? | Yes | CSP-owned | Dependency vulnerability detection is automated via npm audit in CI pipelines and GitHub Dependabot alerts. Automated PRs are generated for vulnerable dependencies. |
| AIS-08.1 | Are processes, procedures, and technical measures defined and implemented to secure APIs? | Yes | Shared CSP and third party | All APIs are secured through Atlassian's authentication and authorization framework. Our apps follow the principle of least privilege for Forge API scopes. We do not expose external APIs. |
| AIS-08.2 | Are reviews and updates for any improvements conducted at least annually, or upon significant changes? | Yes | Shared CSP and third party | API security configurations and Forge permission scopes are reviewed with each release and at least annually. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| BCR-01.1 | Are business continuity management and operational resilience policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Shared CSP and third party | Our apps run on Atlassian Forge, which provides built-in high availability and disaster recovery. Application source code is version-controlled in Git with remote backups. See our Security Policy at yamuno.com/security. |
| BCR-01.2 | Are the policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Security and operational policies are reviewed and updated at least annually or upon significant changes. |
| BCR-02.1 | Are criteria for developing business continuity and operational resiliency strategies and capabilities established based on business disruption and risk impacts? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. |
| BCR-02.2 | Are the risk assessment and impact analysis reviewed and updated at least annually or upon significant changes? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. |
| BCR-03.1 | Are strategies being established to reduce the impact of business disruptions, and are resiliency and recovery from business disruptions being improved? | Yes | Shared CSP and third party | Atlassian Forge provides platform-level resilience. Yamuno maintains version-controlled source code with multiple remote backups to enable rapid recovery and redeployment. |
| BCR-08.1 | Are backups performed periodically? | Yes | Shared CSP and third party | Customer data backups are managed by Atlassian's infrastructure. Source code is backed up via Git with multiple remote repositories. |
| BCR-08.2 | Is the confidentiality, integrity, and availability of the backup ensured? | Yes | Third-party outsourced | Managed by Atlassian Forge. Data confidentiality, integrity, and availability of backups are ensured by Atlassian's SOC 2 certified infrastructure. |
| BCR-08.3 | Can backups be restored appropriately for resiliency? | Yes | Shared CSP and third party | Atlassian manages data restoration. Yamuno can redeploy applications from version-controlled source code at any time. |
| BCR-09.1 | Is a disaster response plan established, documented, approved, applied, evaluated, and maintained to ensure recovery from natural and man-made disasters? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. |
| BCR-09.2 | Is the disaster response plan updated at least annually, and when significant changes occur? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| CCC-01.1 | 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? | Yes | CSP-owned | All changes require peer code review, pass automated testing (including npm audit), and follow staged rollout procedures before production deployment via Forge CLI. |
| CCC-01.2 | Are the policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Change management procedures are reviewed and updated at least annually or upon significant changes to our development workflow. |
| CCC-02.1 | Is a defined quality change control, approval and testing process, incorporating baselines, testing, and release standards, established, maintained and implemented? | Yes | CSP-owned | We maintain a defined quality process: feature branch → code review → automated tests → staging deployment → production deployment. All changes are tracked in Git. |
| CCC-04.1 | Is a procedure to authorize the addition, removal, update, and management of assets owned, controlled, or used by the organization, implemented and enforced? | Yes | Shared CSP and third party | Application deployments are managed through Forge CLI. Code repository access is controlled via GitHub with MFA enforcement. Asset changes are tracked in Git history. |
| CCC-05.1 | Are provisions to limit changes directly impacting service customer-owned environments (tenants) to explicitly authorized requests included within service level agreements? | Yes | Shared CSP and third party | Atlassian Forge enforces tenant isolation. Our apps cannot directly modify customer environments outside of the declared Forge permission scopes. |
| CCC-06.1 | Are change management and configuration baselines established, documented and implemented for all relevant authorized changes on organizational assets? | Yes | Shared CSP and third party | Configuration baselines are maintained in version-controlled configuration files. Forge platform baselines are managed by Atlassian. |
| CCC-06.2 | Are the baselines reviewed and updated at least annually or upon significant changes? | Yes | CSP-owned | Configuration baselines are reviewed with each major release and at least annually. |
| CCC-07.1 | Are detection measures implemented with proactive notification if changes deviate from established baselines? | Yes | Shared CSP and third party | Git-based version control tracks all changes. Forge deployment logs track production changes. Dependency scanning alerts on unexpected changes to third-party libraries. |
| CCC-09.1 | Is a process to proactively roll back changes to a previously known "good state" defined and implemented in case of errors or security concerns? | Yes | Shared CSP and third party | Forge supports deployment rollback to previous versions. Git version control enables reverting to any previous known-good state. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| CEK-01.1 | Are cryptography, encryption, and key management policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Shared CSP and third party | Encryption is enforced at the platform level by Atlassian Forge: TLS 1.2+ for data in transit, AES-256 for data at rest. Yamuno does not implement custom cryptography. See our Security Policy. |
| CEK-01.2 | Are cryptography, encryption, and key management policies and procedures reviewed and updated at least annually, upon significant changes? | Yes | Third-party outsourced | Cryptographic policies are managed by Atlassian's platform team and reviewed as part of their SOC 2 and ISO 27001 certifications. |
| CEK-02.1 | Are cryptography, encryption, and key management roles and responsibilities defined and implemented? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Yamuno does not manage encryption keys or cryptographic operations. |
| CEK-03.1 | Are data protection at-rest and in-transit, and where applicable in use, provided using cryptographic libraries certified to approved standards? | Yes | Third-party outsourced | Managed by Atlassian Forge and AWS. TLS 1.2+ for transit, AES-256 for rest, using certified cryptographic libraries. |
| CEK-04.1 | Are encryption algorithms following industry standards utilized for protecting data, based on the data classification and associated risks? | Yes | Third-party outsourced | Managed by Atlassian. Industry-standard algorithms (AES-256, TLS 1.2+) are enforced at the platform level. |
| CEK-05.1 | 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? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Cryptographic changes are managed by Atlassian. |
| CEK-10.1 | Are cryptographic keys generated using industry-accepted and approved cryptographic libraries that specify algorithm strength and random number generator specifications? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Key generation is managed by Atlassian/AWS infrastructure. |
| CEK-12.1 | Are cryptographic keys rotated based on a cryptoperiod calculated while considering information disclosure risks and legal and regulatory requirements? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Key rotation is managed by Atlassian/AWS infrastructure. |
| CEK-13.1 | 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? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Key revocation is managed by Atlassian/AWS infrastructure. |
| CEK-14.1 | 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? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Key destruction is managed by Atlassian/AWS infrastructure. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| DCS-04.1 | Are policies and procedures for maintaining a safe and secure working environment (in offices, rooms, and facilities) established, documented, approved, communicated, enforced, and maintained? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Yamuno does not operate physical facilities for data processing. |
| DCS-04.2 | Are policies and procedures for maintaining safe, secure working environments (e.g., offices, rooms) reviewed and updated at least annually, or upon significant changes? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. |
| DCS-06.1 | Is the classification and documentation of physical and logical assets based on the organizational business risk? | Yes | Shared CSP and third party | Logical assets (source code, app configurations) are classified based on business risk. Physical infrastructure assets are managed by Atlassian/AWS. |
| DCS-06.2 | Are assets’ classifications reviewed and updated at least annually or upon significant changes? | Yes | CSP-owned | Asset classifications are reviewed at least annually or upon significant changes. |
| DCS-07.1 | Are all relevant physical and logical assets at all CSP sites cataloged and tracked within a secured system? | Yes | Shared CSP and third party | Application assets are tracked in Git repositories. Infrastructure assets are managed by Atlassian Forge. |
| DCS-07.2 | Is the catalogue reviewed and updated at least annually or upon significant changes? | Yes | CSP-owned | Asset inventory is reviewed at least annually. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| DSP-01.1 | 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? | Yes | CSP-owned | Our Privacy Policy (yamuno.com/privacy-policy) covers data classification, protection, and handling throughout the lifecycle. We comply with GDPR and CCPA. |
| DSP-01.2 | Are data security and privacy policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Privacy and security policies are reviewed and updated at least annually or upon significant changes. Last updated April 2026. |
| DSP-03.1 | Is a data inventory created and maintained for sensitive, regulated and personal information (at a minimum)? | Yes | CSP-owned | We maintain a data inventory. Our apps do not collect or store PII outside Atlassian's infrastructure. Website analytics are anonymized. Sub-processors are documented in our Privacy Policy. |
| DSP-03.2 | Is the inventory reviewed and updated at least annually or upon significant changes? | Yes | CSP-owned | Data inventory and sub-processor list are reviewed at least annually. |
| DSP-04.1 | Is data classified according to type and sensitivity levels? | Yes | Shared CSP and third party | Data is classified by sensitivity. Our apps process no customer PII directly. All customer data remains within Atlassian's infrastructure with their classification controls. |
| DSP-05.1 | Is data flow documentation created to identify what data is processed and where it is stored and transmitted? | Yes | Shared CSP and third party | Data flows are documented: all app data flows within Atlassian Forge's sandboxed environment. Website analytics flow to Google Analytics (anonymized). No other external data flows exist. |
| DSP-05.2 | Is data flow documentation reviewed at defined intervals, at least annually, or upon significant changes? | Yes | CSP-owned | Data flow documentation is reviewed at least annually and when new apps or features are released. |
| DSP-06.1 | Is the ownership and stewardship of all relevant personal and sensitive data documented? | Yes | CSP-owned | Data ownership is documented in our Privacy Policy. Customer data is owned by the customer. Yamuno processes data only as necessary to provide services. |
| DSP-06.2 | Is data ownership and stewardship documentation reviewed at least annually? | Yes | CSP-owned | Reviewed at least annually. |
| DSP-07.1 | Are systems, products, and business practices based on security principles by design and per industry best practices? | Yes | Shared CSP and third party | Our apps are built on Atlassian Forge with security by design: sandboxed execution, least-privilege permissions, no external data storage, encrypted communications. |
| DSP-08.1 | Are systems, products, and business practices based on privacy principles by design and according to industry best practices? | Yes | CSP-owned | Privacy by design is implemented: we collect minimal data, anonymize analytics, do not store PII outside Atlassian, and provide data subject rights per GDPR/CCPA. |
| DSP-08.2 | Are systems' privacy settings configured by default and according to all applicable laws and regulations? | Yes | Shared CSP and third party | Privacy settings default to the most protective configuration. Analytics cookies are subject to user consent. Atlassian manages platform-level privacy defaults. |
| DSP-10.1 | 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)? | Yes | Shared CSP and third party | All data transfer occurs within Atlassian's encrypted infrastructure (TLS 1.2+). We do not transfer personal or sensitive data to external systems. |
| DSP-11.1 | 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)? | Yes | CSP-owned | Data subjects can exercise rights (access, modification, deletion) by contacting [email protected]. GDPR and CCPA rights are documented in our Privacy Policy. |
| DSP-12.1 | 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)? | Yes | CSP-owned | Personal data is processed only for declared purposes as documented in our Privacy Policy. Legal bases for processing are defined per GDPR Article 6. |
| DSP-13.1 | 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)? | Yes | CSP-owned | Sub-processor relationships are documented in our Privacy Policy with a maintained sub-processor list. All sub-processors operate under Data Processing Agreements. |
| DSP-14.1 | 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? | Yes | CSP-owned | Sub-processors are disclosed in our Privacy Policy. Customers under DPA may request notification of sub-processor changes before processing initiation. |
| DSP-16.1 | Do data retention, archiving, and deletion practices follow business requirements, applicable laws, and regulations? | Yes | CSP-owned | Data is retained only as long as necessary. Upon subscription termination, data is deleted within 60 days per our EULA (Bonterms v1.0). Immediate deletion available upon request. |
| DSP-17.1 | Are processes, procedures, and technical measures defined and implemented to protect sensitive data throughout its lifecycle? | Yes | Shared CSP and third party | Sensitive data is protected throughout its lifecycle via Atlassian Forge's encrypted infrastructure. Yamuno does not store sensitive data outside of Atlassian's environment. |
| DSP-19.1 | 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? | Yes | Shared CSP and third party | Data is processed within Atlassian's cloud infrastructure. Data residency follows the customer's Atlassian Cloud instance settings. Yamuno does not operate additional data processing locations. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| GRC-01.1 | Are information governance program policies and procedures sponsored by organizational leadership established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | CSP-owned | Our information governance program includes published Security Policy (yamuno.com/security), Privacy Policy (yamuno.com/privacy-policy), EULA, and Terms of Service. |
| GRC-01.2 | Are the policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | All governance policies are reviewed and updated at least annually or upon significant changes. |
| GRC-02.1 | 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? | Yes | CSP-owned | We maintain a risk management approach that includes periodic security reviews, vulnerability management with defined SLAs, dependency monitoring, and incident response procedures. |
| GRC-06.1 | Are roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs defined and documented? | Yes | CSP-owned | Security responsibilities are defined within the organization. Security inquiries are handled via [email protected]. |
| GRC-07.1 | Are all relevant standards, regulations, legal/contractual, and statutory requirements applicable to your organization identified and documented? | Yes | CSP-owned | We track compliance with: GDPR, CCPA, U.S. export control laws, Atlassian Marketplace Partner Agreement, and Bonterms Standard EULA v1.0. |
| GRC-07.2 | Are the identified requirements reviewed at least annually or upon significant changes? | Yes | CSP-owned | Regulatory requirements are reviewed at least annually or when new regulations are identified. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| HRS-03.1 | Are policies and procedures requiring unattended workspaces to conceal confidential data established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | CSP-owned | Team members are required to lock workstations when unattended and protect confidential information in workspaces. |
| HRS-03.2 | Are policies and procedures requiring unattended workspaces to conceal confidential data reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Policies are reviewed and updated at least annually. |
| HRS-04.1 | Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | CSP-owned | Remote work security policies are in place including: disk encryption, MFA on all accounts, secure network connections, and screen lock enforcement. |
| HRS-04.2 | 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? | Yes | CSP-owned | Remote work security policies are reviewed at least annually. |
| HRS-11.1 | Is a security awareness training program for all employees of the organization established, documented, approved, communicated, applied, evaluated and maintained? | Yes | CSP-owned | All team members receive security awareness training covering secure coding (OWASP Top 10), data handling, phishing awareness, and incident reporting. |
| HRS-11.2 | Are regular security awareness training updates provided? | Yes | CSP-owned | Security awareness updates are provided regularly and when new threats or practices are identified. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| IAM-01.1 | Are identity and access management policies and procedures established, documented, approved, communicated, implemented, applied, evaluated, and maintained? | Yes | Shared CSP and third party | Identity and access management for customer-facing apps is handled by Atlassian. Internal access to development tools (GitHub, Atlassian accounts) follows documented IAM policies with MFA enforcement. |
| IAM-01.2 | Are identity and access management policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | IAM policies are reviewed at least annually. |
| IAM-03.1 | Is the inventory of identities managed, stored, and regularly reviewed, and is their level of access monitored? | Yes | Shared CSP and third party | Customer identities are managed by Atlassian. Internal identities (GitHub, Atlassian admin accounts) are inventoried and reviewed periodically. Inactive accounts are deactivated. |
| IAM-04.1 | Is the separation of duties principle employed when implementing information system access? | Yes | Shared CSP and third party | Separation of duties is implemented: code authors cannot approve their own changes. Production deployment requires separate approval. Atlassian enforces tenant-level separation. |
| IAM-05.1 | Is the least privilege principle employed when implementing information system access? | Yes | Shared CSP and third party | Least privilege is enforced: Forge apps request minimum necessary permissions. Internal team access follows least-privilege principles with role-based access. |
| IAM-06.1 | Is an identity access provisioning process defined and implemented which authorizes, records, and communicates data and assets access changes? | Yes | Shared CSP and third party | Access provisioning is managed through GitHub team permissions and Atlassian admin controls. Changes are documented and communicated. |
| IAM-07.1 | Is a process in place to de-provision or modify identity access in a timely manner? | Yes | CSP-owned | Access is revoked promptly when team members leave or change roles. GitHub and Atlassian accounts are deactivated or permissions modified accordingly. |
| IAM-08.1 | 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? | Yes | CSP-owned | Access reviews are conducted periodically and at least annually. Repository and tool access is validated against current team membership and roles. |
| IAM-09.1 | Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated? | Yes | Shared CSP and third party | Privileged access (production deployments, admin panels) is restricted to authorized personnel. Atlassian manages platform-level privileged access segregation. |
| IAM-10.1 | Is an access process defined and implemented to ensure privileged access roles and rights are granted for a limited period? | Yes | Shared CSP and third party | Privileged access sessions are limited in scope. Long-lived tokens are avoided where possible. Atlassian manages platform-level session management. |
| IAM-10.2 | Are procedures implemented to prevent the accumulation of segregated privileged access? | Yes | CSP-owned | Access reviews prevent accumulation of unnecessary privileges. Permissions are reviewed when roles change. |
| IAM-13.1 | 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? | Yes | Shared CSP and third party | MFA is enforced on all internal accounts (GitHub, Atlassian, email). Customer authentication including MFA is managed by Atlassian's identity platform. |
| IAM-13.2 | Are digital certificates or alternatives that achieve an equivalent security level for system identities adopted? | N/A | Third-party outsourced | Managed by Atlassian. Digital certificates for system identities are handled by Atlassian's infrastructure. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| IPY-01.1 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for communications between application interfaces (e.g., APIs)? | Yes | Shared CSP and third party | Our apps communicate exclusively through Atlassian's documented APIs within the Forge sandbox. No external API communications are established. |
| IPY-01.2 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information processing interoperability? | Yes | CSP-owned | Our apps work with standard, interoperable formats: Markdown, LaTeX, HTML, PDF, and standard image formats. |
| IPY-01.3 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for application development portability? | Yes | CSP-owned | Application code is developed using standard web technologies (JavaScript/TypeScript) and deployed through Atlassian Forge's standard deployment framework. |
| IPY-01.4 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information/data exchange, usage, portability, integrity, and persistence? | Yes | Shared CSP and third party | Data exchange follows Atlassian's standard APIs. Our apps support standard formats (Markdown, HTML, PDF, LaTeX) for data portability. Customer data export is available through Atlassian's built-in capabilities. |
| IPY-01.5 | Are interoperability and portability policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Interoperability policies are reviewed at least annually and when new integrations or apps are developed. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| I&S-03.1 | Are communications between environments, services, and applications monitored? | Yes | Third-party outsourced | Managed by Atlassian Forge. All communications between environments are monitored by Atlassian's infrastructure. |
| I&S-03.2 | Are communications between environments, services, and applications encrypted? | Yes | Third-party outsourced | Managed by Atlassian Forge. All communications are encrypted using TLS 1.2+. |
| I&S-03.3 | Are communications between environments, services, and applications restricted to only authenticated and authorized connections, as justified by the business? | Yes | Third-party outsourced | Managed by Atlassian Forge. Communications are restricted to authenticated and authorized connections through Atlassian's auth framework. |
| I&S-03.4 | Are network configurations reviewed at least annually? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Network configurations are managed by Atlassian. |
| I&S-03.5 | Are network configurations supported by the documented justification of all allowed services, protocols, ports, and compensating controls? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Network configurations are managed by Atlassian. |
| I&S-04.1 | 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? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. OS and infrastructure hardening is managed by Atlassian/AWS. |
| I&S-06.1 | Are applications and infrastructures designed, developed, deployed, and configured such that service customer (tenant) access is appropriately segmented, segregated, monitored, and restricted? | Yes | Third-party outsourced | Managed by Atlassian Forge. Tenant isolation and segmentation are enforced by the Forge platform's sandboxed runtime. |
| I&S-07.1 | 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? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. We do not perform server or data migrations. All operations occur within Atlassian's infrastructure. |
| I&S-09.1 | Are processes, procedures, and defense-in-depth techniques defined, implemented, and evaluated for protection, detection, and timely response to network-based attacks? | N/A | Third-party outsourced | Managed by Atlassian Forge platform. Yamuno does not operate external infrastructure, servers, databases, or storage. All app data resides within Atlassian's SOC 2 Type II and ISO 27001 certified cloud environment. Network-based attack protection is managed by Atlassian/AWS. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| LOG-01.1 | Are logging and monitoring policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Shared CSP and third party | Application deployments are logged via Forge. Code changes are tracked in Git with full history. We do not log customer PII or document content. |
| LOG-01.2 | Are policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Logging policies are reviewed at least annually. |
| LOG-04.1 | Is audit log access restricted to authorized identities, and are records of that access maintained? | Yes | Shared CSP and third party | Audit log access is restricted. Git repository access logs are maintained by GitHub. Forge deployment logs are maintained by Atlassian. |
| LOG-05.1 | 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? | Yes | Shared CSP and third party | We monitor dependency vulnerability alerts continuously. Atlassian monitors platform-level security events. Forge deployment anomalies are tracked via Atlassian's monitoring. |
| LOG-05.2 | Is a process established and followed to review and take appropriate and timely actions on detected anomalies? | Yes | CSP-owned | Detected anomalies are reviewed and addressed per our vulnerability severity SLAs. |
| LOG-08.1 | 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? | N/A | Third-party outsourced | Our apps do not log sensitive data. No customer PII or document content is captured in logs. Atlassian manages platform-level log sanitization. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| SEF-03.1 | 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? | Yes | CSP-owned | Our incident response plan includes: immediate containment, customer notification within 72 hours (per GDPR), post-incident summary, and cooperation with Atlassian and regulatory authorities. See yamuno.com/security. |
| SEF-04.1 | Is a structured approach followed to evaluate the effectiveness of incident response plans at planned intervals or upon significant changes? | Yes | CSP-owned | Incident response plan effectiveness is evaluated periodically and when significant changes occur to our services or threat landscape. |
| SEF-07.1 | 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? | Yes | Shared CSP and third party | Security incidents are categorized by severity and responded to per defined SLAs: Critical 24h, High 7d. We cooperate fully with Atlassian's security team. |
| SEF-07.2 | Are these processes and procedures reviewed, updated, and tested at least annually? | Yes | CSP-owned | Incident response procedures are reviewed and updated at least annually. |
| SEF-08.1 | Are processes, procedures, and technical measures for security breach notifications defined and implemented? | Yes | CSP-owned | Breach notification procedures are defined in our Privacy Policy and Security Policy. Affected customers are notified within 72 hours of confirmed impact. |
| SEF-08.2 | Are material security breaches reported (including any relevant supply chain breaches) as per applicable SLAs, laws, and regulations? | Yes | CSP-owned | Material breaches are reported per GDPR requirements (72h to authorities), applicable SLAs, and relevant regulations. Supply chain breaches reported by Atlassian are communicated to affected customers. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| STA-01.1 | Are policies and procedures for supply chain risk management established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | CSP-owned | We maintain supply chain risk management through: sub-processor documentation, DPA requirements, dependency license auditing, and regular review of third-party compliance status. |
| STA-01.2 | Are policies and procedures for supply chain risk management reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Supply chain policies are reviewed at least annually. |
| STA-03.1 | Is the SSRM applied, documented, implemented, and managed throughout the supply chain? | Yes | Shared CSP and third party | The shared security responsibility model is documented: Atlassian manages infrastructure, encryption, authentication, and data residency. Yamuno manages application security, code quality, and vulnerability response. |
| STA-05.1 | Is the shared ownership and applicability of all CSA CCM controls delineated according to the SSRM? | Yes | Shared CSP and third party | Control ownership is delineated between Yamuno (application-level controls) and Atlassian (platform/infrastructure controls) as documented in this CAIQ assessment. |
| STA-08.1 | Is an inventory of all supply chain relationships developed and maintained? | Yes | CSP-owned | Supply chain relationships are documented: Atlassian (Forge hosting, billing, auth), Google Analytics (anonymized website analytics). Sub-processor list is published in our Privacy Policy. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| TVM-02.1 | Are policies and procedures to protect against malware and malicious instructions established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Shared CSP and third party | We use automated dependency scanning (npm audit, Dependabot) to detect vulnerabilities. Atlassian Forge provides platform-level malware protection. |
| TVM-02.2 | Are asset management and malware protection policies and procedures reviewed and updated at least annually, or upon significant changes? | Yes | CSP-owned | Malware protection and vulnerability management policies are reviewed at least annually. |
| TVM-03.1 | Are processes, procedures, and technical measures defined, implemented, and evaluated for vulnerability detection on organizationally managed assets at least monthly? | Yes | Shared CSP and third party | Dependency vulnerability scanning runs in CI on every build. GitHub Dependabot monitors for new CVEs continuously. Atlassian performs platform-level vulnerability scanning. |
| TVM-05.1 | Are processes, procedures, and technical measures defined, implemented, and evaluated to update detection tools, threat signatures, and compromise indicators weekly (or more frequent) basis? | Yes | Shared CSP and third party | Dependency vulnerability databases are updated continuously by npm/GitHub. Atlassian updates platform-level threat signatures. We monitor CVE feeds for our technology stack. |
| TVM-08.1 | Are processes, procedures and technical measures defined, implemented and evaluated based on identified risks to support scheduled and emergency responses to vulnerability identification? | Yes | CSP-owned | Vulnerability response follows defined severity SLAs: Critical 24h, High 7d, Medium 30d, Low 90d. Emergency responses are supported for zero-day vulnerabilities. |
| TVM-10.1 | 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? | Yes | CSP-owned | We use CVSS scoring and our defined severity SLAs for risk-based prioritization. Threats are assessed based on exploitability, impact, and data exposure potential. |
| TVM-11.1 | Is a process defined and implemented to track and report vulnerability identification and remediation activities that include stakeholder notification? | Yes | CSP-owned | Vulnerability identification and remediation activities are tracked in our issue management system. Stakeholders are notified of Critical and High findings. Our responsible disclosure program is published at yamuno.com/security. |
| ID | Question | Answer | Ownership | Implementation |
|---|---|---|---|---|
| UEM-02.1 | 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? | Yes | CSP-owned | Approved development tools and services are documented. Only authorized applications are used for accessing and processing company data. |
| UEM-04.1 | Is an inventory of all endpoints used and maintained to store, access and process company data? | Yes | CSP-owned | An inventory of endpoints used to access company data and development systems is maintained. |
| UEM-05.1 | 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? | Yes | CSP-owned | Endpoint security policies include: disk encryption, MFA enforcement, up-to-date OS, and screen lock requirements for all development devices. |
| UEM-06.1 | Are all relevant interactive-use endpoints configured to require an automatic lock screen? | Yes | CSP-owned | All development workstations are configured to require automatic screen lock after a period of inactivity. |
| UEM-09.1 | Are anti-malware detection and prevention technology services configured on managed endpoints? | Yes | CSP-owned | Development endpoints run up-to-date OS with built-in anti-malware protection (macOS XProtect/Gatekeeper or equivalent). |
| UEM-10.1 | Are software firewalls configured on managed endpoints? | Yes | CSP-owned | Software firewalls are enabled on all managed development endpoints. |
| UEM-13.1 | Are processes, procedures, and technical measures defined, implemented, and evaluated to enable remote company data deletion on managed endpoint devices? | Yes | CSP-owned | Remote wipe capabilities are available for managed devices through platform-level device management (e.g., Find My Mac, MDM). |
For security reviews, vendor questionnaires, or Data Processing Agreement requests:
Last Updated: April 4, 2026