Security Questionnaire — CAIQ Lite v4
Last updated: 2026-06-04 · Vendor: Sparxsys Solutions Limited · App: QR Code for Jira
This page contains our responses to the CSA Consensus Assessments Initiative Questionnaire (CAIQ) Lite v4, aligned to the Cloud Controls Matrix (CCM) v4.1.
Context: QR Code for Jira runs entirely on Atlassian Forge — Atlassian's serverless platform. Atlassian owns and operates all underlying infrastructure (data centres, servers, networking, virtualisation) and holds ISO 27001 / SOC 2 certifications for it. Sparxsys is responsible for the application code layer only. Many infrastructure-level controls are therefore inherited from Atlassian.
A&A — Audit & Assurance
| ID | Question | Answer | Notes |
|---|
| A&A-01.1 | Are audit and assurance policies established, documented, applied, and maintained? | Yes | Basic security policies applied to development lifecycle. |
| A&A-01.2 | Are policies reviewed and updated at least annually? | Yes | |
| A&A-02.1 | Are independent audit and assurance assessments conducted at least annually? | No | Security is reviewed internally on each release. Third-party audits planned as the business grows. |
| A&A-03.1 | Are assessments performed according to risk-based plans? | Yes | Risk-based approach used to prioritise dependency vulnerability findings. |
| A&A-04.1 | Is compliance verified regarding relevant standards and statutory requirements? | Yes | Atlassian Marketplace Security Requirements and GDPR principles verified before each release. |
| A&A-06.1 | Is a risk-based corrective action plan established? | Yes | Vulnerability findings triaged by CVSS severity; Critical/High block release. |
| A&A-06.2 | Is remediation status reviewed and reported? | Yes | Tracked in the source repository and release notes. |
AIS — Application & Interface Security
| ID | Question | Answer | Notes |
|---|
| AIS-01.1 | Are application security policies established and maintained? | Yes | Secure development guidelines enforced: input encoding, no secret storage, read-only scopes. |
| AIS-01.2 | Reviewed and updated at least annually? | Yes | |
| AIS-02.1 | Are baseline security requirements established for applications? | Yes | Forge platform requirements enforced; encodeURIComponent for all user inputs; read-only manifest scopes. |
| AIS-04.1 | Is an SDLC process defined per security requirements? | Yes | Feature branch → PR review → CI tests (≥95% coverage) → Forge CLI deploy. |
| AIS-05.1 | Does the testing strategy outline acceptance criteria for new releases? | Yes | All PRs require passing Jest suite (backend + both frontends) before merge. |
| AIS-05.2 | Is testing automated? | Yes | Bitbucket Pipelines CI on every push. |
| AIS-06.1 | Are strategies in place to deploy code securely? | Yes | Deployed via authenticated Atlassian Forge CLI — no custom server deployments. |
| AIS-06.2 | Is deployment and integration automated where possible? | Yes | Bitbucket Pipelines CI/CD with test gate before deploy. |
| AIS-07.1 | Are application security vulnerabilities remediated following defined processes? | Yes | npm audit on every CI build; Critical/High findings block release. |
| AIS-07.2 | Is remediation automated when possible? | Partial | npm audit fix applied where safe; manual review for force-upgrades. |
BCR — Business Continuity Management & Operational Resilience
| ID | Question | Answer | Notes |
|---|
| BCR-01.1 | Are BCM and operational resilience policies established? | Partial | App resilience is inherited from Atlassian Forge's multi-region, highly available infrastructure. No separate formal BCM plan. |
| BCR-02.1 | Are BC/resilience strategies established? | Yes (inherited) | Atlassian Forge provides built-in redundancy. The app is stateless; only KVS admin config is persisted. |
| BCR-04.1 | Is a business continuity plan maintained? | No | Atlassian's Forge SLA covers availability. No separate app-level BCP. |
| BCR-08.1 | Is cloud data periodically backed up? | Yes (inherited) | Admin config in @forge/kvs is managed by Atlassian. No user data is stored. |
| BCR-08.2 | Is CIA of backup data ensured? | Yes (inherited) | Atlassian Forge KVS ensures confidentiality, integrity, and availability. |
| BCR-09.1 | Is a disaster response plan established? | Not Applicable | Handled entirely by Atlassian Forge infrastructure. |
CCC — Change Control & Configuration Management
| ID | Question | Answer | Notes |
|---|
| CCC-01.1 | Are risk management policies for changing assets established? | Yes | All changes go through PR review before merging to main branch. |
| CCC-02.1 | Is a quality change control process followed? | Yes | PR workflow with mandatory CI test pass and peer review before merge. |
| CCC-04.1 | Is unauthorised addition/removal of assets restricted? | Yes | Branch protection on main; only authorised team members can merge. |
| CCC-05.1 | Are there provisions to limit changes impacting customer environments? | Yes | Forge's versioned deployment model; no breaking changes without a new version. |
| CCC-07.1 | Are detection measures implemented for deviations from baselines? | Yes | CI pipeline detects regressions via automated test suite. |
| CCC-09.1 | Is there a process to roll back changes? | Yes | git revert and Forge CLI can redeploy previous versions. |
CEK — Cryptography, Encryption & Key Management
| ID | Question | Answer | Notes |
|---|
| CEK-01.1 | Are cryptography, encryption, and key management policies established? | Yes (inherited) | All encryption managed by Atlassian Forge. The app uses no custom cryptography or key management. |
| CEK-03.1 | Are data at-rest and in-transit cryptographically protected? | Yes (inherited) | All Forge API calls use HTTPS/TLS. KVS data encrypted at rest by Atlassian. |
| CEK-04.1 | Are appropriate data protection encryption algorithms used? | Yes (inherited) | Atlassian Forge uses industry-standard encryption. The app adds no custom cryptography. |
| CEK-08.1 | Are CSPs providing CSCs with the capacity to manage their own encryption keys? | Not Applicable | App stores only admin configuration data, not personal or sensitive data requiring customer-managed keys. |
DCS — Datacenter Security
All DCS controls: Not Applicable.
Sparxsys operates no data centres, servers, or physical infrastructure. The app runs entirely on Atlassian's Forge serverless platform. Physical and datacenter security is covered by Atlassian's ISO 27001 / SOC 2 certifications.
DSP — Data Security & Privacy Lifecycle Management
| ID | Question | Answer | Notes |
|---|
| DSP-01.1 | Are data security and privacy policies established? | Yes | Privacy Policy published at /docs/PRIVACY. Data handling is minimal by design. |
| DSP-01.2 | Reviewed and updated at least annually? | Yes | |
| DSP-02.1 | Are industry-accepted methods applied for secure data disposal? | Not Applicable | App stores no data on physical media. Forge KVS data deleted via admin UI or on app uninstall. |
| DSP-03.1 | Is a data inventory created for sensitive and personal information? | Yes | The only data stored: { id, key, name } per Jira project in KVS — admin configuration only. No PII. |
| DSP-04.1 | Is data classified by type and sensitivity? | Yes | Single classification: app configuration data (non-sensitive). No PII or sensitive data stored. |
| DSP-05.1 | Is data flow documentation created? | Yes | All data flows within the Atlassian boundary: Jira API → Forge resolver → KVS. QR codes generated client-side and not persisted. |
| DSP-07.1 | Are systems based on security-by-design principles? | Yes | Read-only scopes only. No external service calls. QR codes generated locally. |
| DSP-08.1 | Are privacy settings configured by default? | Yes | No data collection by default. Admin config stored only on explicit admin action. |
| DSP-09.1 | Is a DPIA conducted when processing personal data? | Not Applicable | App does not process personal data. |
| DSP-11.1 | Are processes in place to enable data subject access/modification/deletion requests? | Not Applicable | No personal data stored. Admin can delete project config entries via the admin UI. |
| DSP-12.1 | Is personal data processed lawfully and for declared purposes? | Yes | No personal data is collected or processed. |
| DSP-16.1 | Do data retention practices follow applicable laws? | Yes | Admin config data retained only as long as the admin chooses; no automated retention needed as no PII involved. |
GRC — Governance, Risk & Compliance
| ID | Question | Answer | Notes |
|---|
| GRC-01.1 | Are information governance program policies established? | Yes | Basic information security policy applied; development practices documented. |
| GRC-01.2 | Reviewed and updated at least annually? | Yes | |
| GRC-02.1 | Is there an enterprise risk management program? | Partial | Informal risk assessment process. Security risks reviewed before each release. |
| GRC-03.1 | Are all relevant policies reviewed at least annually? | Yes | |
| GRC-05.1 | Has an information security program been developed and implemented? | Yes | Atlassian Marketplace Security Requirements compliance process serves as the framework. |
| GRC-06.1 | Are roles and responsibilities for governance defined and documented? | Yes | Development and security responsibilities assigned within the team. |
| GRC-07.1 | Are relevant standards, regulations, and legal requirements identified? | Yes | GDPR principles, Atlassian Marketplace Partner Agreement, and Atlassian Security Requirements identified and followed. |
HRS — Human Resources Security
| ID | Question | Answer | Notes |
|---|
| HRS-01.1 | Are background verification policies established? | Yes | Background checks conducted for all team members with access to production systems. |
| HRS-02.1 | Are acceptable use policies for organisational assets established? | Yes | Team members agree to data handling and security responsibilities. |
| HRS-05.1 | Are return procedures for assets by terminated employees established? | Yes | Repository and Atlassian developer account access revoked upon departure. |
| HRS-07.1 | Are employees required to sign an employment agreement? | Yes | All team members sign NDAs and employment agreements covering data protection. |
| HRS-08.1 | Are security provisions included within employment agreements? | Yes | Confidentiality and acceptable use provisions included. |
| HRS-11.1 | Is a security awareness training program established? | Yes | Security awareness communicated to all team members; Atlassian developer security documentation reviewed annually. |
| HRS-11.2 | Are regular security awareness training updates provided? | Yes | Annual review of Atlassian security guidelines and OWASP Top 10. |
IAM — Identity & Access Management
| ID | Question | Answer | Notes |
|---|
| IAM-01.1 | Are IAM policies established? | Yes | Atlassian Forge handles all end-user identity and authentication. Internal access managed via Atlassian and GitHub with MFA enforced. |
| IAM-01.2 | Reviewed and updated at least annually? | Yes | |
| IAM-02.1 | Are strong password policies established? | Yes (inherited) | Atlassian account policies enforce strong passwords and MFA for all users. |
| IAM-04.1 | Is the separation of duties principle employed? | Yes | PR review process: no developer approves their own code changes. |
| IAM-05.1 | Is the least privilege principle employed? | Yes | App requests only read-only Jira scopes. No write or admin permissions. |
| IAM-06.1 | Is a user access provisioning process defined? | Yes | Atlassian handles provisioning for app users. Internal repo access managed via GitHub organisation settings. |
| IAM-07.1 | Is there a process to de-provision access for leavers? | Yes | GitHub and Atlassian developer access revoked same day of departure. |
| IAM-08.1 | Are reviews and revalidation of user access completed? | Yes | Repository access reviewed at least annually. |
| IAM-09.1 | Are processes for segregation of privileged access defined? | Yes | All API calls use asUser() — no elevated app-level privileges. asApp() is not used. |
| IAM-13.1 | Are measures in place to ensure users are identifiable through unique identification? | Yes (inherited) | Every user authenticated through Atlassian's identity system with a unique account ID. |
| IAM-14.1 | Are MFA processes defined for authenticating access? | Yes (inherited) | Atlassian enforces MFA for Jira users. Team members use MFA on all developer accounts. |
| IAM-16.1 | Is access to data and system functions authorised and restricted? | Yes | asUser() scopes all actions to the authenticated user's existing Jira permissions. |
IPY — Interoperability & Portability
| ID | Question | Answer | Notes |
|---|
| IPY-01.1 | Are policies for communications between application services established? | Yes | All inter-service communication uses Atlassian Forge Bridge API and Jira REST APIs over HTTPS. |
| IPY-02.1 | Are CSCs able to retrieve their data via an application interface? | Yes | Admin-configured project list in KVS retrievable. All Jira data remains fully accessible via Atlassian APIs. |
| IPY-03.1 | Are cryptographically secure and standardised network protocols implemented? | Yes (inherited) | All communication uses Forge's HTTPS/TLS endpoints. No custom protocols. |
| IPY-04.1 | Do agreements include CSC data access provisions upon contract termination? | Yes | Atlassian Marketplace Partner Agreement covers data portability. App data in KVS is deleted on uninstall. |
IVS — Infrastructure & Virtualization Security
All IVS controls: Not Applicable or Inherited from Atlassian.
Sparxsys manages no servers, hypervisors, or network infrastructure. All infrastructure and virtualisation security is handled by Atlassian's Forge platform (ISO 27001 / SOC 2 certified). The app does benefit from the following Forge-provided controls:
- Production and non-production environments separated (Forge dev/staging/production).
- Multi-tenant isolation enforced by Atlassian's Forge runtime.
- All network communication encrypted via TLS.
LOG — Logging & Monitoring
| ID | Question | Answer | Notes |
|---|
| LOG-01.1 | Are logging and monitoring policies established? | Yes | Forge platform logs all function invocations. App-level errors logged via console.error. |
| LOG-01.2 | Reviewed and updated at least annually? | Yes | |
| LOG-02.1 | Are audit log security and retention measures defined? | Yes (inherited) | Atlassian Forge maintains platform-level audit logs. App log access restricted to authorised developers via Atlassian developer console. |
| LOG-07.1 | Are logging requirements for system events implemented? | Yes | console.error used in all catch blocks throughout resolvers and frontend components. No user data or PII logged — only error messages. |
| LOG-08.1 | Are audit records generated with relevant security information? | Yes (inherited) | Atlassian Forge generates platform audit records for all app invocations. |
| LOG-09.1 | Are audit records protected from unauthorised access? | Yes (inherited) | Forge log access restricted to authorised developers via Atlassian developer console with MFA. |
SEF — Security Incident Management, E-Discovery & Cloud Forensics
| ID | Question | Answer | Notes |
|---|
| SEF-01.1 | Are policies for security incident management established? | Yes | Security incidents reported to Atlassian via ecosystem.atlassian.net. A named security contact is registered. |
| SEF-01.2 | Reviewed and updated annually? | Yes | |
| SEF-02.1 | Are policies for timely management of security incidents established? | Yes | Security incidents acknowledged within 48 hours; critical vulnerabilities addressed per Atlassian Marketplace Bug Fix Policy. |
| SEF-03.1 | Is a security incident response plan established? | Yes | Plan: triage → notify Atlassian → patch release → customer notification via Marketplace listing. |
| SEF-04.1 | Is the incident response plan tested? | Partial | Tabletop exercise conducted; no formal documented drill. |
| SEF-06.1 | Are processes to triage security-related events defined? | Yes | Security issues triaged using CVSS severity scoring. |
| SEF-07.1 | Are security breach notification procedures defined? | Yes | Customer notification follows Atlassian Marketplace Security Incident Communication Template. |
| SEF-07.2 | Are security breaches reported per applicable SLAs, laws, and regulations? | Yes | GDPR 72-hour notification obligation acknowledged and planned for. |
| SEF-08.1 | Are points of contact maintained for applicable regulation authorities? | Yes | Atlassian ecosystem.atlassian.net security contact registered. |
STA — Supply Chain Management, Transparency & Accountability
| ID | Question | Answer | Notes |
|---|
| STA-01.1 | Are SSRM policies established? | Yes | Shared responsibility acknowledged: Atlassian owns infrastructure; Sparxsys owns app code. |
| STA-01.2 | Reviewed and updated annually? | Yes | |
| STA-04.1 | Is shared ownership per SSRM defined? | Yes | Atlassian: infrastructure, runtime, data storage. Sparxsys: application code, business logic, releases. |
| STA-07.1 | Is an inventory of supply chain relationships maintained? | Yes | Primary dependency: Atlassian Forge. npm dependencies tracked in package-lock.json. |
| STA-08.1 | Are risk factors for supply chain organisations reviewed? | Yes | npm audit run on each build; critical dependencies monitored. |
| STA-09.1 | Do service agreements incorporate mutually agreed terms? | Yes | Atlassian Marketplace Partner Agreement and Forge Terms of Service govern the relationship. |
| STA-11.1 | Is there a process for internal assessments to confirm conformance? | Yes | CI/CD pipeline enforces conformance on every commit. |
TVM — Threat & Vulnerability Management
| ID | Question | Answer | Notes |
|---|
| TVM-01.1 | Are policies to identify, report, and remediate vulnerabilities established? | Yes | npm audit on every CI build; Critical/High vulnerabilities block release. |
| TVM-01.2 | Reviewed and updated at least annually? | Yes | |
| TVM-02.1 | Are policies to protect against malware on managed assets established? | Yes | Developer endpoints protected by AV software. App runs on Atlassian Forge with no user-accessible server. |
| TVM-03.1 | Are scheduled and emergency vulnerability responses defined? | Yes | Critical vulnerabilities: emergency patch release. Routine: regular release cycle. |
| TVM-05.1 | Are processes to identify updates for third-party/open-source libraries established? | Yes | npm dependency monitoring; npm audit and Dependabot alerts reviewed regularly. |
| TVM-06.1 | Is periodic third-party penetration testing performed? | No | No formal penetration testing as a small ISV. Atlassian performs platform-level pen testing. |
| TVM-08.1 | Is vulnerability remediation prioritised using a risk-based model? | Yes | CVSS severity: Critical/High patched immediately; Medium/Low on next regular release. |
| TVM-09.1 | Is a process defined to report vulnerability identification and remediation activities? | Yes | Tracked via GitHub issues; communicated via Marketplace release notes and Atlassian vulnerability notification template. |
| TVM-10.1 | Are metrics for vulnerability identification established? | Partial | npm audit output reviewed per build. No formal metrics dashboard. |
UEM — Universal Endpoint Management
| ID | Question | Answer | Notes |
|---|
| UEM-01.1 | Are endpoint management policies established? | Yes | Policies for developer laptops: full-disk encryption, AV software, OS patch management. |
| UEM-01.2 | Reviewed and updated at least annually? | Yes | |
| UEM-02.1 | Is there a documented list of approved applications for endpoints? | Yes | Developer tooling standardised: Forge CLI, Node.js, approved IDEs. |
| UEM-04.1 | Is an inventory of all endpoints maintained? | Yes | Small team; endpoint inventory maintained. |
| UEM-05.1 | Are policies and controls enforced to access organisational data? | Yes | Production access via Atlassian developer console with MFA. Code access via GitHub with MFA. |
| UEM-06.1 | Are interactive-use endpoints configured with an automatic lock screen? | Yes | Required for all developer machines. |
| UEM-08.1 | Is information protected from unauthorised disclosure on managed endpoints? | Yes | Developer laptops use full-disk encryption. No customer data stored locally. |
| UEM-09.1 | Are anti-malware detection services configured on managed endpoints? | Yes | AV software required on all developer machines. |
| UEM-10.1 | Are software firewalls configured on managed endpoints? | Yes | OS-level firewall enabled on all developer machines. |
Summary
| Domain | Posture |
|---|
| DCS, IVS (infrastructure) | Fully inherited from Atlassian Forge (ISO 27001 / SOC 2) |
| CEK, BCR (crypto / continuity) | Primarily inherited; app-layer not applicable |
| AIS, CCC (app security, change control) | Strong — CI/CD, ≥95% test coverage, PR gates |
| DSP (data privacy) | Strong — no PII stored, privacy by design |
| IAM | Strong — asUser() only, read-only scopes, MFA enforced |
| TVM | Good — npm audit in CI; no formal pen testing yet |
| LOG | Good — error-only logging, no sensitive data logged |
| A&A, GRC (governance) | Basic — appropriate for small ISV |
| SEF (incident management) | Defined — Atlassian Marketplace process followed |
For questions about this assessment, contact support@sparxsys.com.