Security Self-Assessment — CAIQ Lite v4.1.0 (CSA STAR Level 1)
Point-in-time as of 2026-09-25 · Arkidor for Confluence
Scope. This page reproduces the completed Cloud Security Alliance (CSA) Consensus Assessment Initiative Questionnaire (CAIQ Lite v4.1.0) self-assessment for Arkidor for Confluence only — the Atlassian Forge app distributed through the Atlassian Marketplace. It does not cover the standalone Arkidor web application at arkidor.io, which is a separate product. The 138 questions below are grouped by the 17 CSA CCM domains; only the response, SSRM ownership, and notes columns have been completed by the vendor.
Status & disclaimer
STATUS: PUBLISHED — CSA STAR Level 1 Self-Assessment (unaudited self-attestation). Point-in-time as of 2026-09-25.
This is a CSA STAR Level 1 self-assessment completed by Knaap (Arthur van der Knaap) for the Atlassian Forge Cloud app “Arkidor for Confluence.” It is a self-attestation only. It has NOT been audited, independently verified, reviewed, certified, or attested by the Cloud Security Alliance or any third party, and it does NOT constitute a CSA STAR Level 2 certification or any form of independent assurance.
The responses reflect the vendor’s good-faith understanding of its security posture as of 2026-09-25 and are not continuously updated; the posture may change after that date. Many infrastructure controls are inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001) and are the responsibility of Atlassian, not the vendor.
This questionnaire is provided “AS IS”, for informational purposes only, without warranty of any kind, and creates no contractual obligation or representation. It is qualified in its entirety by, and subject to, the Arkidor for Confluence Terms of Use and Data Processing Addendum, which govern in the event of any conflict. Nothing in this document is a representation or warranty beyond those expressly set out in those documents.
Cloud Security Alliance attribution & notices
This document reproduces the Cloud Security Alliance (CSA) Consensus Assessment Initiative Questionnaire (CAIQ Lite v4.1.0), which is built on the CSA Cloud Controls Matrix (CCM) v4.
Cloud Controls Matrix and CAIQ © Copyright 2026 Cloud Security Alliance. All rights reserved. Reproduced, without modification, for a CSA STAR Level 1 self-assessment. The CAIQ questions and CCM control text are unaltered and all CSA copyright, trademark, and other proprietary notices have been retained.
“Cloud Security Alliance”, “CSA”, “CCM”, “Cloud Controls Matrix”, “CAIQ”, and “STAR” are trademarks or registered trademarks of the Cloud Security Alliance. Only the response, SSRM, and notes columns have been completed by Knaap (Arthur van der Knaap).
This self-assessment is not sponsored, reviewed, endorsed, certified, attested, or verified by the Cloud Security Alliance. Its completion and publication do not imply any CSA certification, STAR Level 2 attestation, or CSA endorsement of Arkidor for Confluence.
CSA-native spreadsheet (secondary download)
The HTML tables on this page are the authoritative version; the CSA-native workbook (.xlsx), which retains the CSA Introduction/licence tab and copyright notices in full, is provided as a download for tooling and offline review: download the CSA-native spreadsheet (.xlsx).
Answer summary
138 questions answered: 96 Yes, 38 No, 4 NA. Answering approach is honest and conservative — inherited infrastructure controls are attributed to the Atlassian Forge platform (SOC 2 Type II / ISO 27001); controls asking for formal programs, certifications, audits, or staffing the solo vendor does not have are answered “No” (or “NA” where genuinely not applicable) rather than overclaimed.
| Domain | Yes | No | NA | Summary note |
|---|---|---|---|---|
| A&A — Audit & Assurance | 0 | 5 | 0 | No independent audits of the vendor; infra audited by Atlassian (SOC 2/ISO 27001). |
| AIS — Application & Interface Security | 7 | 1 | 0 | Real strength — secure SDLC, code review, SCA scanning, least-privilege Forge scopes, VDP. |
| BCR — Business Continuity Management and Operational Resilience | 4 | 6 | 0 | No formal vendor BC/DR program; resilience inherited from Atlassian + stateless/redeployable design. |
| CCC — Change Control and Configuration Management | 7 | 2 | 0 | Lightweight git-based change control, test/lint/typecheck gates, immutable Forge deploys, rollback via redeploy. |
| CEK — Cryptography, Encryption & Key Management | 10 | 0 | 0 | All cryptography/key management inherited from Atlassian; app performs no custom crypto. |
| DCS — Datacenter Security | 4 | 2 | 0 | No vendor datacenters/facilities (inherited); no formal vendor asset-classification scheme. |
| DSP — Data Security and Privacy Lifecycle Management | 20 | 0 | 0 | Strongest domain — GDPR docs (DPA, sub-processor list, LIA, controller/processor memo), privacy-by-design, telemetry minimization. |
| GRC — Governance, Risk and Compliance | 2 | 4 | 0 | No formal governance/ERM program (solo); regulatory scope (GDPR) is identified and documented. |
| HRS — Human Resources | 0 | 2 | 4 | Mostly NA/No — no workforce; founder applies personal endpoint controls. |
| IAM — Identity & Access Management | 7 | 6 | 0 | End-user IAM + MFA inherited from Atlassian; least-privilege scopes; no SoD (solo). |
| IPY — Interoperability & Portability | 3 | 2 | 0 | Standards-based interoperability/portability via open ArchiMate XML; data survives uninstall. |
| I&S — Infrastructure Security | 9 | 0 | 0 | All network/infrastructure/virtualization controls inherited from Atlassian. |
| LOG — Logging and Monitoring | 4 | 2 | 0 | Infra logging inherited; app telemetry scrubbed of content; IP transmitted for delivery but not stored; no vendor SIEM/SOC. |
| SEF — Security Incident Management, E-Discovery, & Cloud Forensics | 4 | 2 | 0 | VDP + GDPR breach-notification documented; no formal IR testing (solo). |
| STA — Supply Chain Management, Transparency, and Accountability | 4 | 1 | 0 | SCA dependency scanning, sub-processor list/SSRM documented; no formal annual SCRM review. |
| TVM — Threat & Vulnerability Management | 6 | 1 | 0 | Continuous dependency/SCA scanning, CVSS-based prioritization, VDP; no formal annual malware-policy review. |
| UEM — Universal Endpoint Management | 5 | 2 | 0 | Founder endpoint hardening (FDE, auto-lock, AV, firewall); no MDM/remote-wipe; no customer data on endpoints. |
A&A — Audit & Assurance
No independent audits of the vendor; infra audited by Atlassian (SOC 2/ISO 27001).
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| A&A-02.1 | Are independent audit and assurance assessments conducted according to relevant standards at least annually? | No | Shared CSP and 3rd-party | The solo vendor does not commission independent third-party audits of itself (limited resources). Underlying infrastructure is independently audited: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | No | Shared CSP and 3rd-party | No vendor-run risk-based audit program. Platform infra is assessed by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| A&A-04.1 | Is compliance verified regarding all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit? | No | Shared CSP and CSC | Vendor self-assesses GDPR compliance via internal docs (DPA, LIA, controller/processor memo) but this is NOT independently audited/verified. Conservative 'No'. |
| A&A-06.1 | Is a risk-based corrective action plan to remediate audit findings established, documented, approved, communicated, applied, evaluated, and maintained? | No | CSP-owned | No formal audit program exists, so there is no documented corrective-action plan for audit findings. VDP-driven remediation covers reported vulnerabilities instead. |
| A&A-06.2 | Is the remediation status of audit findings regularly reviewed and reported to relevant stakeholders? | No | CSP-owned | No audit-finding remediation tracking/reporting program (no audit program). Vulnerability remediation is tracked via the VDP/issue tracker. |
AIS — Application & Interface Security
Real strength — secure SDLC, code review, SCA scanning, least-privilege Forge scopes, VDP.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| AIS-02.1 | Are baseline requirements to secure applications established, documented, and maintained? | Yes | Shared CSP and 3rd-party | Published Security Policy defines application security baselines; app requests least-privilege Forge scopes and runs as the signed-in user. Platform baselines: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | Secure SDLC in place: peer/self code review, dependency & SCA scanning, automated tests (Vitest/Playwright), typecheck/lint gates before Forge deploy. |
| 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 3rd-party | Code is deployed only through the standardized Forge CLI/pipeline (forge deploy/install) with signed, immutable app versions. Platform manages runtime. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| AIS-06.2 | Is the deployment and integration of application code automated where possible? | Yes | CSP-owned | Build/test/deploy are automated (npm scripts + release script; Forge CLI). Integration and checks run automatically before release. |
| AIS-07.1 | Are application security vulnerabilities remediated following defined processes? | Yes | CSP-owned | Published VDP (security@arkidor.io) with severity-based remediation targets; vulnerabilities triaged and fixed via defined process and issue tracker. |
| AIS-07.2 | Is the remediation of application security vulnerabilities automated when possible? | No | CSP-owned | Detection is automated (SCA/dependency alerts) but remediation itself is performed manually by the founder; no automated auto-fix pipeline. Conservative 'No'. |
| AIS-08.1 | Are processes, procedures, and technical measures defined and implemented to secure APIs? | Yes | Shared CSP and 3rd-party | App exposes no public API; it uses Forge resolvers and the Confluence REST bridge with least-privilege scopes, running as the signed-in user. Interface transport/authN: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| AIS-08.2 | Are reviews and updates for any improvements conducted at least annually, or upon significant changes? | Yes | CSP-owned | Scopes/interfaces are reviewed on each release and upon significant change (rather than a fixed annual date). |
BCR — Business Continuity Management and Operational Resilience
No formal vendor BC/DR program; resilience inherited from Atlassian + stateless/redeployable design.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| BCR-01.1 | Are business continuity management and operational resilience policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? | No | Third-party outsourced | Solo vendor maintains no formal documented BC/operational-resilience program. Infrastructure resilience is Atlassian's: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| BCR-01.2 | Are the policies and procedures reviewed and updated at least annually, or upon significant changes? | No | Third-party outsourced | No vendor BC policy to review annually. Platform resilience maintained by Atlassian. |
| BCR-02.1 | Are criteria for developing business continuity and operational resiliency strategies and capabilities established based on business disruption and risk impacts? | No | Third-party outsourced | No formal vendor BC strategy/BIA. Architecture is stateless (no vendor-held customer data); infra continuity is Atlassian's. |
| BCR-02.2 | Are the risk assessment and impact analysis reviewed and updated at least annually or upon significant changes? | No | Third-party outsourced | No formal vendor BIA/risk assessment maintained on an annual cycle. |
| 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 3rd-party | Resilience by design: app is stateless, customer data lives in the customer's tenant (survives uninstall), and app code/config is versioned and redeployable. Infra resilience: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| BCR-08.1 | Are backups performed periodically? | Yes | Third-party outsourced | Customer content (attachments) is backed up as part of the customer's Confluence tenant by Atlassian; vendor source/config is in version control. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| BCR-08.2 | Is the confidentiality, integrity, and availability of the backup ensured? | Yes | Third-party outsourced | Backup confidentiality/integrity/availability for tenant data is managed by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| BCR-08.3 | Can backups be restored appropriately for resiliency? | Yes | Third-party outsourced | Restore/resiliency of tenant data is provided by Atlassian; vendor app is redeployable from version control. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| BCR-09.1 | Is a disaster response plan established, documented, approved, applied, evaluated, and maintained to ensure recovery from natural and man-made disasters? | No | Third-party outsourced | Vendor maintains no own documented disaster-response plan. Infrastructure DR is Atlassian's (Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center.). App is stateless and redeployable. |
| BCR-09.2 | Is the disaster response plan updated at least annually, and when significant changes occur? | No | Third-party outsourced | No vendor DR plan to update annually; infrastructure DR maintained by Atlassian. |
CCC — Change Control and Configuration Management
Lightweight git-based change control, test/lint/typecheck gates, immutable Forge deploys, rollback via redeploy.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| 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 | Change management is implemented via a git-based workflow with code review, automated tests, and controlled Forge releases; lightweight but documented in the SDLC/release process. |
| CCC-01.2 | Are the policies and procedures reviewed and updated at least annually, or upon significant changes? | No | CSP-owned | Change process evolves with each release rather than under a formal annual review cadence. Conservative 'No'. |
| 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 | Quality gates before release: automated tests (Vitest/Playwright), typecheck, lint, code review, and a defined release/versioning script. |
| 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 | CSP-owned | Additions/removals/updates to code and config assets are authorized and recorded through version control (commits/PRs) and the release process. |
| 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 3rd-party | App only affects tenant environments within its declared least-privilege Forge scopes and runs as the signed-in user; a Support & SLA policy governs changes. Platform enforces scope limits. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 3rd-party | Configuration baseline is the versioned Forge manifest (scopes, modules, permissions); changes are tracked in version control. Runtime baseline: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| CCC-06.2 | Are the baselines reviewed and updated at least annually or upon significant changes? | Yes | CSP-owned | Manifest/config baseline is reviewed at each release and upon significant change. |
| CCC-07.1 | Are detection measures implemented with proactive notification if changes deviate from established baselines? | No | Shared CSP and 3rd-party | No automated configuration-drift detection tooling operated by the solo vendor. Mitigated because Forge deployments are immutable/atomic (platform-managed). Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 3rd-party | Rollback is supported: previous app versions can be redeployed from version control, and Forge retains prior deployed versions. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
CEK — Cryptography, Encryption & Key Management
All cryptography/key management inherited from Atlassian; app performs no custom crypto.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| CEK-01.1 | Are cryptography, encryption, and key management policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| CEK-02.1 | Are cryptography, encryption, and key management roles and responsibilities defined and implemented? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| CEK-10.1 | Are cryptographic keys generated using industry-accepted and approved cryptographic libraries that specify algorithm strength and random number generator specifications? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| CEK-12.1 | Are cryptographic keys rotated based on a cryptoperiod calculated while considering information disclosure risks and legal and regulatory requirements? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | The app performs no custom cryptography or key management; encryption in transit/at rest and all key lifecycle operations are provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
DCS — Datacenter Security
No vendor datacenters/facilities (inherited); no formal vendor asset-classification scheme.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| 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? | Yes | Third-party outsourced | Vendor operates no datacenters or facilities that store customer data; physical/environmental security is provided by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | Physical-security policies are maintained and reviewed by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| DCS-06.1 | Is the classification and documentation of physical and logical assets based on the organizational business risk? | No | CSP-owned | Solo serverless vendor maintains no formal physical/logical asset classification scheme. Note: vendor holds no customer data at rest (data resides in the tenant); assets are limited to source code and cloud accounts. |
| DCS-06.2 | Are assets’ classifications reviewed and updated at least annually or upon significant changes? | No | CSP-owned | No formal asset-classification scheme to review annually. |
| DCS-07.1 | Are all relevant physical and logical assets at all CSP sites cataloged and tracked within a secured system? | Yes | Third-party outsourced | Vendor operates no CSP datacenter sites; physical/logical datacenter assets are cataloged and tracked by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| DCS-07.2 | Is the catalogue reviewed and updated at least annually or upon significant changes? | Yes | Third-party outsourced | Datacenter asset catalog maintained/reviewed by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
DSP — Data Security and Privacy Lifecycle Management
Strongest domain — GDPR docs (DPA, sub-processor list, LIA, controller/processor memo), privacy-by-design, telemetry minimization.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| 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 | Shared CSP and 3rd-party | Data security & privacy governed by a published Security Policy plus GDPR docs (DPA v5.1.0, sub-processor list, LIA, controller/processor memo). Platform data-handling controls: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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/security docs are versioned (e.g., DPA v5.1.0) and updated on significant/regulatory changes. |
| DSP-03.1 | Is a data inventory created and maintained for sensitive, regulated and personal information (at a minimum)? | Yes | CSP-owned | Processing inventory is documented via GDPR records: customer ArchiMate content (in tenant) and minimal scrubbed error telemetry; sub-processor list enumerates data recipients. |
| DSP-03.2 | Is the inventory reviewed and updated at least annually or upon significant changes? | Yes | CSP-owned | Inventory updated when processing or sub-processors change. |
| DSP-04.1 | Is data classified according to type and sensitivity levels? | Yes | CSP-owned | Data is classified: customer model content = customer-owned/confidential (in tenant); telemetry = minimized and content-scrubbed; limited diagnostic personal data (IP transmitted but not stored, browser/OS, URLs reduced to the path or the site address only). Documented in privacy docs. |
| DSP-05.1 | Is data flow documentation created to identify what data is processed and where it is stored and transmitted? | Yes | CSP-owned | Data flows documented in the controller/processor memo, LIA and sub-processor list (customer tenant -> app; scrubbed telemetry -> Sentry EU ingest). |
| DSP-05.2 | Is data flow documentation reviewed at defined intervals, at least annually, or upon significant changes? | Yes | CSP-owned | Data-flow docs reviewed on significant change (e.g., sub-processor/telemetry changes). |
| DSP-06.1 | Is the ownership and stewardship of all relevant personal and sensitive data documented? | Yes | CSP-owned | Ownership/stewardship documented in the controller/processor memo: customer is controller of in-tenant model content (Knaap is processor); Knaap is controller for content-scrubbed error telemetry (Sentry is Knaap's processor). |
| DSP-06.2 | Is data ownership and stewardship documentation reviewed at least annually? | Yes | CSP-owned | Ownership/stewardship documentation reviewed on change. |
| DSP-07.1 | Are systems, products, and business practices based on security principles by design and per industry best practices? | Yes | Shared CSP and 3rd-party | Security-by-design: client-side app, least-privilege scopes, runs as signed-in user, no vendor-side storage of customer content, telemetry content scrubbed. Platform controls: Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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: sendDefaultPii=false, IP not stored, telemetry content scrubbed, data minimization, customer content stays in tenant. |
| DSP-08.2 | Are systems' privacy settings configured by default and according to all applicable laws and regulations? | Yes | CSP-owned | Privacy-protective defaults: telemetry minimized by default (sendDefaultPii=false; IP transmitted but not stored); least-privilege scopes requested. |
| 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 3rd-party | Personal-data transfer protected: Sentry EU-region ingest, Sentry US processor under EU-U.S. DPF + SCC Module 2, content scrubbed, DPA accepted; transport encryption inherited. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | Shared CSP and CSC | Data-subject rights: customer content is directly managed by the customer in its tenant; for telemetry, requests are handled by Knaap as controller via support@arkidor.io (Privacy Policy §9). |
| 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 | Purpose limitation documented in the LIA/privacy docs; telemetry used only for error diagnostics. |
| 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-processing governed by DPA, SCCs and a maintained sub-processor list (Atlassian, Sentry, AWS). |
| 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-processor identities/roles disclosed to customers via the published sub-processor list prior to processing. |
| DSP-16.1 | Do data retention, archiving, and deletion practices follow business requirements, applicable laws, and regulations? | Yes | Shared CSP and 3rd-party | Retention/deletion: customer content retention is customer-controlled in-tenant (survives uninstall); telemetry events retained 90 days, then deleted. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| DSP-17.1 | Are processes, procedures, and technical measures defined and implemented to protect sensitive data throughout its lifecycle? | Yes | Shared CSP and 3rd-party | Lifecycle protection via inherited encryption, least-privilege scopes, telemetry scrubbing and data minimization. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 3rd-party | Data locations documented in the sub-processor list (Atlassian hosting regions, Sentry EU ingest, AWS). Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
GRC — Governance, Risk and Compliance
No formal governance/ERM program (solo); regulatory scope (GDPR) is identified and documented.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| GRC-01.1 | Are information governance program policies and procedures sponsored by organizational leadership established, documented, approved, communicated, applied, evaluated, and maintained? | No | CSP-owned | Solo vendor: a published Security Policy and GDPR docs exist, but there is no formal enterprise information-governance PROGRAM sponsored by a leadership structure. Conservative 'No'. |
| GRC-01.2 | Are the policies and procedures reviewed and updated at least annually, or upon significant changes? | No | CSP-owned | No formal governance program under an annual review cadence. |
| 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? | No | CSP-owned | No formal, documented enterprise risk-management (ERM) program; risk decisions are made informally by the founder. |
| GRC-06.1 | Are roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs defined and documented? | No | CSP-owned | Solo vendor: all governance roles are held by the single founder; no documented role matrix/segregation exists. |
| GRC-07.1 | Are all relevant standards, regulations, legal/contractual, and statutory requirements applicable to your organization identified and documented? | Yes | CSP-owned | Applicable requirements (notably GDPR) are identified and documented in the DPA, LIA and controller/processor memo. |
| GRC-07.2 | Are the identified requirements reviewed at least annually or upon significant changes? | Yes | CSP-owned | Regulatory scope reviewed on significant/regulatory change. |
HRS — Human Resources
Mostly NA/No — no workforce; founder applies personal endpoint controls.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| HRS-03.1 | Are policies and procedures requiring unattended workspaces to conceal confidential data established, documented, approved, communicated, applied, evaluated, and maintained? | NA | CSP-owned | No workforce beyond the sole founder, so no clear-desk/unattended-workspace policy for staff. Founder applies endpoint controls (full-disk encryption, auto-lock). No customer data stored on endpoints. |
| HRS-03.2 | Are policies and procedures requiring unattended workspaces to conceal confidential data reviewed and updated at least annually, or upon significant changes? | NA | CSP-owned | Not applicable (solo, no workforce). |
| 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? | No | CSP-owned | No documented remote-work data-protection policy (solo). Founder works remotely with a hardened endpoint (FDE, auto-lock, updated OS, OS AV/firewall); customer data is not stored on endpoints. |
| 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? | No | CSP-owned | No formal policy to review annually (solo). |
| HRS-11.1 | Is a security awareness training program for all employees of the organization established, documented, approved, communicated, applied, evaluated and maintained? | NA | CSP-owned | No employees to train; the sole founder has a security background. No formal security-awareness training program exists. Conservative NA. |
| HRS-11.2 | Are regular security awareness training updates provided? | NA | CSP-owned | Not applicable (no workforce to train). |
IAM — Identity & Access Management
End-user IAM + MFA inherited from Atlassian; least-privilege scopes; no SoD (solo).
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| IAM-01.1 | Are identity and access management policies and procedures established, documented, approved, communicated, implemented, applied, evaluated, and maintained? | Yes | Shared CSP and 3rd-party | End-user authentication/identity is provided by Atlassian/Confluence; the app requests least-privilege scopes and runs as the signed-in user. Vendor's own accounts (Atlassian, git, Sentry, AWS) use MFA. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| IAM-01.2 | Are identity and access management policies and procedures reviewed and updated at least annually, or upon significant changes? | No | Shared CSP and CSC | Vendor's small access footprint is reviewed on change rather than on a formal annual cadence. Platform IAM policies maintained by Atlassian. |
| IAM-03.1 | Is the inventory of identities managed, stored, and regularly reviewed, and is their level of access monitored? | Yes | Shared CSP and 3rd-party | End-user identity inventory is managed by Atlassian; the vendor's own limited accounts are known and access-controlled. App maintains no separate identity store. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| IAM-04.1 | Is the separation of duties principle employed when implementing information system access? | No | CSP-owned | As a solo operator, true separation of duties is not achievable. Compensating controls: least-privilege scopes, platform IAM, version-control history. Conservative 'No'. |
| IAM-05.1 | Is the least privilege principle employed when implementing information system access? | Yes | Shared CSP and 3rd-party | Least privilege enforced: app requests minimal Forge scopes and runs as the signed-in user; vendor accounts use least-privilege where configurable. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 3rd-party | End-user access provisioning handled by Atlassian/Confluence; vendor's own account provisioning is minimal and controlled. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| IAM-07.1 | Is a process in place to de-provision or modify identity access in a timely manner? | Yes | Shared CSP and 3rd-party | End-user deprovisioning handled by Atlassian; app access is removed on uninstall; vendor account changes are actioned promptly. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | No | Shared CSP and CSC | No formal periodic access-recertification process (small footprint, solo). Conservative 'No'. |
| IAM-09.1 | Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated? | No | CSP-owned | Solo operator cannot segregate privileged roles. Compensating: least privilege + platform IAM. Conservative 'No'. |
| IAM-10.1 | Is an access process defined and implemented to ensure privileged access roles and rights are granted for a limited period? | No | Shared CSP and 3rd-party | No just-in-time/time-bound privileged-access process operated by the solo vendor. Platform-side privileged access is governed by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| IAM-10.2 | Are procedures implemented to prevent the accumulation of segregated privileged access? | No | CSP-owned | Accumulation-prevention controls require segregated roles, which is not applicable to a single operator. Conservative 'No'. |
| 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 3rd-party | MFA enforced on vendor administrative accounts (Atlassian/Marketplace, git, Sentry, AWS); end-user authN incl. MFA is provided by Atlassian/Confluence. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| IAM-13.2 | Are digital certificates or alternatives that achieve an equivalent security level for system identities adopted? | Yes | Third-party outsourced | System/app identity and TLS certificates are platform-managed; the app uses Forge-issued tokens/identity. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
IPY — Interoperability & Portability
Standards-based interoperability/portability via open ArchiMate XML; data survives uninstall.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| IPY-01.1 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for communications between application interfaces (e.g., APIs)? | No | Shared CSP and 3rd-party | No formal documented interface-communications policy (solo). Interface comms are governed by Forge (least-privilege scopes, platform-managed transport). Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| IPY-01.2 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information processing interoperability? | Yes | CSP-owned | Interoperability is standards-based: the app reads/writes the ArchiMate Open Exchange Format (open XML), avoiding proprietary lock-in. |
| IPY-01.3 | Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for application development portability? | Yes | CSP-owned | Portability supported via open ArchiMate XML import/export; customer data survives app uninstall (no proprietary retention). |
| 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 | CSP-owned | Data exchange/portability/integrity/persistence: open XML import/export with round-trip fidelity; content persists in the customer tenant and survives uninstall. |
| IPY-01.5 | Are interoperability and portability policies and procedures reviewed and updated at least annually, or upon significant changes? | No | CSP-owned | No formal annual review cadence for interoperability/portability policies (solo); revisited on significant change. |
I&S — Infrastructure Security
All network/infrastructure/virtualization controls inherited from Atlassian.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| I&S-03.1 | Are communications between environments, services, and applications monitored? | Yes | Third-party outsourced | Network/service communications monitoring is provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| I&S-03.2 | Are communications between environments, services, and applications encrypted? | Yes | Third-party outsourced | Communications are encrypted in transit (TLS) by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| I&S-03.3 | Are communications between environments, services, and applications restricted to only authenticated and authorized connections, as justified by the business? | Yes | Shared CSP and 3rd-party | Platform restricts comms to authenticated/authorized connections; app adds least-privilege scopes and runs as signed-in user. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| I&S-03.4 | Are network configurations reviewed at least annually? | Yes | Third-party outsourced | Network configuration is managed and reviewed by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| I&S-03.5 | Are network configurations supported by the documented justification of all allowed services, protocols, ports, and compensating controls? | Yes | Shared CSP and 3rd-party | Platform maintains network service/port justifications; app declares required scopes/permissions in its versioned Forge manifest. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | Serverless: vendor manages no OS/hypervisor/control plane; hardening is Atlassian's. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | Shared CSP and 3rd-party | Tenant isolation/segregation provided by Atlassian Forge; app additionally runs as the signed-in user within tenant scope. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | App deploys via Forge over encrypted channels; no server/data migration operated by the vendor. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | Yes | Third-party outsourced | Network defense-in-depth (DDoS/WAF/network protection) provided by the platform. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
LOG — Logging and Monitoring
Infra logging inherited; app telemetry scrubbed of content; IP transmitted for delivery but not stored; no vendor SIEM/SOC.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| LOG-01.1 | Are logging and monitoring policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Shared CSP and 3rd-party | Infrastructure logging is provided by the platform (Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center.). App error telemetry to Sentry is configured per documented decisions (EU ingest, sendDefaultPii=false, IP not stored, content scrubbed, DPA v5.1.0). |
| LOG-01.2 | Are policies and procedures reviewed and updated at least annually, or upon significant changes? | No | Shared CSP and 3rd-party | No formal annual review cadence for a vendor logging policy; Sentry config revisited on change. Platform log policies maintained by Atlassian. |
| LOG-04.1 | Is audit log access restricted to authorized identities, and are records of that access maintained? | Yes | Shared CSP and 3rd-party | Infra audit-log access is restricted by Atlassian; Sentry project access is restricted to the founder (MFA). Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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? | No | Shared CSP and 3rd-party | No vendor-operated SIEM or 24/7 SOC to correlate security logs (limited resources, solo). Platform-level anomaly detection is Atlassian's. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| LOG-05.2 | Is a process established and followed to review and take appropriate and timely actions on detected anomalies? | Yes | CSP-owned | Founder reviews Sentry error alerts and remediates; security reports via the VDP are triaged and actioned. This is error/VDP-focused, not a formal 24/7 security-monitoring process. |
| 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? | Yes | CSP-owned | Vendor-side scrubbing removes/omits sensitive content and PII before telemetry leaves the client (sendDefaultPii=false, IP not stored, content scrubbed). |
SEF — Security Incident Management, E-Discovery, & Cloud Forensics
VDP + GDPR breach-notification documented; no formal IR testing (solo).
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| 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 | Incident/vulnerability handling documented in the Security Policy/VDP (contact security@arkidor.io) with severity-based targets; breach-notification obligations covered in the DPA/GDPR docs. Lightweight (solo). |
| SEF-04.1 | Is a structured approach followed to evaluate the effectiveness of incident response plans at planned intervals or upon significant changes? | No | CSP-owned | No formal periodic IR-plan testing/tabletop exercises (solo, limited resources). Conservative 'No'. |
| 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 | CSP-owned | VDP defines severity-based triage and remediation targets enabling timely response by category/severity. |
| SEF-07.2 | Are these processes and procedures reviewed, updated, and tested at least annually? | No | CSP-owned | IR process is updated on change but not formally reviewed/tested on an annual cadence (solo). Conservative 'No'. |
| SEF-08.1 | Are processes, procedures, and technical measures for security breach notifications defined and implemented? | Yes | CSP-owned | Breach-notification process documented via the DPA/GDPR docs (incl. GDPR controller/processor notification obligations). |
| SEF-08.2 | Are material security breaches reported (including any relevant supply chain breaches) as per applicable SLAs, laws, and regulations? | Yes | CSP-owned | Vendor commits to reporting material breaches (incl. relevant sub-processor breaches) per GDPR/DPA timelines. |
STA — Supply Chain Management, Transparency, and Accountability
SCA dependency scanning, sub-processor list/SSRM documented; no formal annual SCRM review.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| STA-01.1 | Are policies and procedures for supply chain risk management established, documented, approved, communicated, applied, evaluated, and maintained? | Yes | Shared CSP and 3rd-party | Supply-chain risk managed via dependency/SCA scanning, a maintained sub-processor list, and use of vetted providers (Atlassian, Sentry, AWS). Lightweight but active (solo). |
| STA-01.2 | Are policies and procedures for supply chain risk management reviewed and updated at least annually, or upon significant changes? | No | CSP-owned | No formal annual SCRM policy-review cadence; sub-processor list and dependencies revisited on change. Conservative 'No'. |
| STA-03.1 | Is the SSRM applied, documented, implemented, and managed throughout the supply chain? | Yes | Shared CSP and 3rd-party | SSRM is documented via this CAIQ (SSRM ownership column) and the sub-processor list; responsibilities delineated between vendor, Atlassian and Sentry/AWS. |
| STA-05.1 | Is the shared ownership and applicability of all CSA CCM controls delineated according to the SSRM? | Yes | CSP-owned | Shared ownership of CCM controls is delineated in this questionnaire's SSRM Control Ownership column. |
| STA-08.1 | Is an inventory of all supply chain relationships developed and maintained? | Yes | CSP-owned | Supply-chain inventory maintained: sub-processor list (Atlassian, Sentry, AWS) plus a dependency inventory (lockfile / SBOM-capable). |
TVM — Threat & Vulnerability Management
Continuous dependency/SCA scanning, CVSS-based prioritization, VDP; no formal annual malware-policy review.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| 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 3rd-party | Serverless app runs no vendor-managed servers; platform provides infrastructure malware defenses (Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center.). Founder endpoints run OS-native anti-malware. Malicious-input risks mitigated in secure SDLC. |
| TVM-02.2 | Are asset management and malware protection policies and procedures reviewed and updated at least annually, or upon significant changes? | No | CSP-owned | No formal annual malware-policy review cadence (solo). Conservative 'No'. |
| TVM-03.1 | Are processes, procedures, and technical measures defined, implemented, and evaluated for vulnerability detection on organizationally managed assets at least monthly? | Yes | CSP-owned | Dependency/SCA vulnerability scanning runs on every build/commit (continuously), exceeding a monthly cadence. |
| 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 3rd-party | SCA/advisory databases (e.g., GitHub Advisory/Dependabot) update continuously; platform threat signatures maintained by Atlassian. Inherited from the Atlassian Forge platform (SOC 2 Type II / ISO 27001); see Atlassian Trust Center. |
| 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 | VDP defines scheduled and emergency responses to identified vulnerabilities with severity-based targets. |
| 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 | Risk-based prioritization uses CVSS severity (industry-recognized) to drive remediation, per the Security Policy/VDP. |
| 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 | Vulnerabilities are tracked (issue tracker) and remediation communicated via release notes and the security contact; VDP enables stakeholder notification. |
UEM — Universal Endpoint Management
Founder endpoint hardening (FDE, auto-lock, AV, firewall); no MDM/remote-wipe; no customer data on endpoints.
| Question ID | Question | Answer | SSRM ownership | Notes |
|---|---|---|---|---|
| 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? | No | CSP-owned | No formal documented allow-list of approved apps/sources for endpoints (solo). Founder installs software only from trusted/official sources. Conservative 'No'. |
| UEM-04.1 | Is an inventory of all endpoints used and maintained to store, access and process company data? | Yes | CSP-owned | Founder maintains awareness/inventory of the small set of managed endpoints (1-2 devices) used for development. |
| 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 controls self-applied by the founder: full-disk encryption, auto-lock, OS updates, anti-malware, firewall. No MDM. No customer data stored on endpoints. |
| UEM-06.1 | Are all relevant interactive-use endpoints configured to require an automatic lock screen? | Yes | CSP-owned | Founder's endpoints are configured with an automatic lock screen. |
| UEM-09.1 | Are anti-malware detection and prevention technology services configured on managed endpoints? | Yes | CSP-owned | OS-native anti-malware (e.g., Microsoft Defender / macOS protections) is enabled on endpoints. |
| UEM-10.1 | Are software firewalls configured on managed endpoints? | Yes | CSP-owned | OS software firewall is enabled on endpoints. |
| UEM-13.1 | Are processes, procedures, and technical measures defined, implemented, and evaluated to enable remote company data deletion on managed endpoint devices? | No | CSP-owned | No MDM/remote-wipe capability (solo). Mitigated: full-disk encryption and no customer data stored on endpoints. Conservative 'No'. |