Nexus security self-assessment (CAIQ Lite)
| Product | Nexus: test management for Jira Cloud (an Atlassian Forge app) |
| Vendor | Resync Labs (Resync Consulting Limited, New Zealand) |
| Security contact | nexus-support@resync.co.nz (subject "Security") |
| Questionnaire | CSA CAIQ-Lite, 71 questions in 16 domains |
| Last updated | 02/11/2026 |
How to read the answers
- Yes: Resync runs the control for Nexus.
- Yes (inherited): Atlassian runs the control. Nexus runs entirely on Atlassian Forge, with no Resync servers, no Forge Remote and no external database. Under the Forge shared-responsibility model, Atlassian provides hosting, physical security, network security, encryption at rest (AES-256) and in transit (TLS 1.2+), backups, platform logging and monitoring, and infrastructure vulnerability management. Forge is SOC 2 attested and ISO 27001 certified (developer.atlassian.com/platform/forge/forge-soc2-iso27001/; reports on the Atlassian Trust Center). This label is used only where that page, or Atlassian's Forge hosted-storage documentation, covers the control.
- Partially: some of the control exists, and the note says what is missing. The CSA template accepts only Yes, No and NA. Before uploading the CSV to a tool that enforces this, change "Partially" to "No" and keep the note. Also change "Yes (inherited)" to "Yes".
- No: the control does not exist today. Every No and Partially is listed in Gaps and recommended actions.
- N/A: there is nothing for the control to apply to.
- Commitments: some Yes answers rest on a recurring review (monthly log review, yearly access review, October annual reviews). The note says so, and gives the first review date. They are written into Resync's security policy.
Facts behind several answers
- Hosting: Nexus is a Forge app with no Resync servers. All customer data is stored in Jira and Forge-hosted storage inside Atlassian. Nexus does not claim Atlassian data-residency (pinning) status.
- Editions and AI: there is one edition. AI is optional. When a Jira admin connects their own AI provider account, the content needed for an AI action goes from Forge straight to that provider. AI runs on one requirement per request, and every output is a draft for human review.
- Egress: 19 exact hosts are declared in
manifest.yml: 5 AI providers, 10 hosts for migration sources (Xray, Zephyr Scale, Zephyr Squad and AIO Tests) and 4 for CI services (api.github.com,gitlab.com,dev.azure.com,api.bitbucket.org). Migration data flows into Jira only, and only after an admin enters credentials. Nothing goes to a CI host until a project admin connects a CI service and a user presses Run in CI; then only the run details the admin ticked are sent (project key, cycle key and label, environment, build and the results address), never issue content or a Nexus API key. CI services are the customer's own, not Resync sub-processors. No new Jira scope was added. - Scopes: 16 narrowly scoped permissions. There is no site-admin scope and no
separate granular delete-content scope. The classic
write:jira-workscope includes Jira issue deletion; Nexus restricts permanent deletion to supported actions explicitly requested by authorised users. - Permissions: permissions inherit Jira's, and every route checks them on the server (build rule 14).
- Logs: logs hold no End-User Data.
- Read API: a project admin can create an API key with the opt-in Read test data
permission. Whoever holds it can read that one project's test records through the
nexus-read-apiweb trigger on Forge. Restricted issues are never returned and sensitive test data values are always masked. - Secrets: secrets are in Forge secret storage. CI and ingestion API keys are stored only as salted hashes.
- Personal data: the production 2.0.1 baseline includes the Personal Data Reporting API, a default seven-day reporting cycle and resumable background processing. This integration was also included in production 2.0.0.
Summary
| Answer | Count |
|---|---|
| Yes | 40 |
| Yes (inherited) | 14 |
| Partially | 5 |
| No | 6 |
| N/A | 6 |
| Total | 71 |
The Yes answers that rest on a recurring commitment (monthly log review, yearly access review, October annual reviews) say so in their notes.
AIS — Application & Interface Security
| ID | Question | Answer | Note |
|---|---|---|---|
| AIS-01.2 | Do you use an automated source code analysis tool to detect security defects in code prior to production? | Yes | For application changes, automated checks run on pull requests and pushes to main; website-only changes are excluded: TypeScript typecheck, typed ESLint with project security rules (no dangerouslySetInnerHTML, no logging of caught error messages), source-scan tests that fail on customer text or identifiers in log lines, and an npm audit gate that fails at High. Since 19/10/2026 a Semgrep scan (community packs p/typescript, p/nodejs, p/secrets, p/owasp-top-ten, no account, fails on any ERROR finding) is in CI as .github/workflows/semgrep.yml, and Dependabot proposes weekly npm and Actions updates. The same scan was run on the whole codebase on 19/10/2026: one finding (a shell-injection pattern in the manual publish workflow), fixed. First green GitHub run: https://github.com/ResyncNZ/Nexus/actions/runs/39236018199 (19/10/2026). |
| AIS-01.5 | (SaaS only) Do you review your applications for security vulnerabilities and address any issues prior to deployment to production? | Yes | Every workstream closes with a dated compliance review against the binding build rules (parameterised SQL, no raw HTML, XXE-hardened parsing, a server-side permission check on every route). Whole-app security reviews ran on 24/09/2026 and 27/09/2026, and findings were fixed or recorded as owner-accepted risks. Thousands of automated tests (backend Jest plus frontend Vitest; the last recorded figures are about 16,400 Jest and 5,850 Vitest (10/10/2026)), adversarial live "hunts" on a development site and an E2E regression suite form the release checks. The release log records the checks and exceptions for each release: 2.0.1 was owner-approved after development testing on 02/11/2026 before the full manual E2E was finished. A security review is done before every deployment. |
| AIS-02.1 | Are all identified security, contractual, and regulatory requirements for customer access contractually addressed and remediated prior to granting customers access to data, assets, and information systems? | Yes | Customers install Nexus through the Atlassian Marketplace. The Marketplace terms, the Nexus terms (reviewed by counsel), the privacy policy and the DPA apply, and the Jira admin approves every declared scope and egress host at install. The DPA is published at nexus.resync.nz/dpa/. |
| AIS-03.1 | Does your data management policies and procedures require audits to verify data input and output integrity routines? | Yes | The binding build rules require parameterised SQL, untrusted-input validation and XXE-safe parsing of uploaded results, and every compliance review checks them. Every stored JSON shape carries a schemaVersion and is read through a versioned upgrader. Workflow validators fail closed. A backup restore is hash-checked record by record. |
AAC — Audit Assurance & Compliance
| ID | Question | Answer | Note |
|---|---|---|---|
| AAC-02.1 | Do you allow tenants to view your SOC2/ISO 27001 or similar third-party audit or certification reports? | No | Resync holds no SOC 2 report or ISO 27001 certificate. The platform layer is covered by Atlassian: the Forge platform is SOC 2 attested and ISO 27001 certified, and its reports are on the Atlassian Trust Center. |
| AAC-02.2 | Do you conduct network penetration tests of your cloud service infrastructure at least annually? | N/A | Resync runs no servers or networks. Nexus runs entirely on Atlassian Forge, whose infrastructure security, including vulnerability management and testing, is Atlassian's responsibility under the Forge shared-responsibility model. |
| AAC-02.3 | Do you conduct application penetration tests of your cloud infrastructure regularly as prescribed by industry best practices and guidance? | Partially | In-house only. Internal security reviews (24/09/2026 and 27/09/2026) and repeated adversarial live testing ("hunts") against a dev site cover authorisation, injection, data exposure and the webtrigger APIs. No independent third-party penetration test has been done, and Nexus is not yet in the Marketplace Security Bug Bounty (planned after listing). |
| AAC-03.1 | Do you have a program in place that includes the ability to monitor changes to the regulatory requirements in relevant jurisdictions, adjust your security program for changes to legal requirements, and ensure compliance with relevant regulatory requirements? | Partially | Atlassian's security requirements and Forge platform rules are tracked and re-verified against developer.atlassian.com before each release. Counsel reviewed the privacy position (NZ Privacy Act 2020, GDPR via NZ adequacy, CCPA service provider) on 09/10/2026. There is no formal regulatory-monitoring programme or calendar. |
BCR — Business Continuity Management & Operational Resilience
| ID | Question | Answer | Note |
|---|---|---|---|
| BCR-02.1 | Are business continuity plans subject to testing at planned intervals or upon significant organizational or environmental changes to ensure continuing effectiveness? | No | There is no written business continuity plan. Service availability is Atlassian's (Forge-hosted). An uninstall, reinstall and restore drill was run live on 28/09/2026, with measured recovery times, but it is not scheduled. Key-person dependency is the main business continuity risk (see Gaps). |
| BCR-10.1 | Are policies and procedures established and made available for all personnel to adequately support services operations' roles? | Yes | Operating procedures live in the private repository: binding build rules, release and patch policy with security-fix SLAs, deploy runbook, backup and recovery guide, the information security policy and the release-gate test plan. They are available to the owner and the employees who work on Nexus. |
| BCR-11.1 | Do you have technical capabilities to enforce tenant data retention policies? | Yes | A nightly sweep enforces retention. Working history defaults to 180 days and is configurable per project from 30 to 3,650 days. Audit records default to 7 years and are configurable from 1 to 10 years. A finding still awaiting review is never pruned. Customer Jira issues are never deleted by Nexus. |
| BCR-11.3 | Have you implemented backup or recovery mechanisms to ensure compliance with regulatory, statutory, contractual or business requirements? | Yes (inherited) | Atlassian backs up Forge-hosted storage and Jira data. Nexus also gives Jira admins a self-service Backup & Restore export of everything Nexus stores, with secrets excluded. Atlassian keeps storage for 28 days after an uninstall, and Resync can ask Atlassian to re-link it within 21 days. |
| BCR-11.7 | Do you test your backup or redundancy mechanisms at least annually? | Yes | Backup and restore have automated tests and were proven live on 28/09/2026: a fresh install took about 2 minutes, and a restore took about 45 seconds per 10,000 records. Atlassian tests platform backups. Resync repeats the backup and restore test every October; first re-test October 2026. |
CCC — Change Control & Configuration Management
| ID | Question | Answer | Note |
|---|---|---|---|
| CCC-04.1 | Do you have controls in place to restrict and monitor the installation of unauthorized software onto your systems? | Yes | The software supply chain is gated. Dependencies come from the npm registry, any other source fails CI unless reviewed and pinned by integrity hash, GitHub Actions are pinned to commit SHAs, SBOMs are produced per commit, and deploys run from a clean worktree at a tested commit. On work computers, software installation is managed and restricted. |
DSI — Data Security & Information Lifecycle Management
| ID | Question | Answer | Note |
|---|---|---|---|
| DSI-03.1 | Do you provide standardized (e.g. ISO/IEC) non-proprietary encryption algorithms (3DES, AES, etc.) to tenants in order for them to protect their data if it is required to move through public networks (e.g., the Internet)? | Yes (inherited) | All traffic to Jira, Custom UI and the Nexus webtriggers uses Atlassian-managed TLS 1.2+. Outbound calls to the 19 declared egress hosts are HTTPS only, with no redirects followed. The CI reporters and runner refuse plain-http Nexus URLs. |
| DSI-03.2 | Do you utilize open encryption methodologies any time your infrastructure components need to communicate with each other via public networks (e.g., Internet-based replication of data from one environment to another)? | Yes (inherited) | Resync operates no infrastructure. Communication between Forge, Jira and storage is Atlassian's and is encrypted with TLS 1.2+. Nexus's own outbound calls (AI provider, migration source, CI service) are HTTPS to fixed hosts. |
| DSI-05.1 | Do you have procedures in place to ensure production data shall not be replicated or used in non-production environments? | Yes | Forge development, staging and production environments are separate installations with separate storage, and Resync has no copy of customer data to replicate. Testing uses Resync's own Jira sites and synthetic or sample data only. Customer backup files stay with the customer. |
| DSI-07.1 | Do you support the secure deletion (e.g., degaussing/cryptographic wiping) of archived and backed-up data? | Yes (inherited) | Atlassian deletes Forge-hosted storage after its post-uninstall retention period, about 28 days soft-deleted. Resync keeps no copies or backups of customer data. Nexus retention sweeps delete expired rows while installed. Media sanitisation is Atlassian's. |
| DSI-07.2 | Can you provide a published procedure for exiting the service arrangement, including assurance to sanitize all computing resources of tenant data once a customer has exited your environment or has vacated a resource? | Yes | The published DPA (§8) and privacy policy describe exit: export everything with Backup & Restore, Jira data stays with the customer, and Atlassian deletes Nexus storage after uninstall. If an admin turned on "Move old details to Jira" (cold storage), those issue properties stay in Jira after uninstall unless the admin moves them back first. |
DCS — Datacenter Security
| ID | Question | Answer | Note |
|---|---|---|---|
| DCS-01.2 | Do you maintain a complete inventory of all of your critical assets located at all sites/ or geographical locations and their assigned ownership? | Yes | App assets are inventoried in code: the manifest (modules, scopes and egress hosts), CycloneDX SBOMs per commit, a personal-data inventory, and a release manifest for downloadable helpers. Resync also keeps a list of company devices and systems with their owners. |
| DCS-02.1 | Are physical security perimeters (e.g., fences, walls, barriers, guards, gates, electronic surveillance, physical authentication mechanisms, reception desks, and security patrols) implemented for all areas housing sensitive data and information systems? | Yes (inherited) | All customer data is in Atlassian's cloud (Jira and Forge-hosted storage). Physical security is Atlassian's and its cloud providers', and is covered by Forge's SOC 2 and ISO 27001. Resync has no premises that hold customer data. |
| DCS-09.1 | Do you restrict physical access to information assets and functions by users and support personnel? | Yes (inherited) | Same as DCS-02.1: customer data is only in Atlassian data centres. Resync staff have no physical access to it. |
EKM — Encryption & Key Management
| ID | Question | Answer | Note |
|---|---|---|---|
| EKM-02.1 | Do you have a capability to allow creation of unique encryption keys per tenant? | No | Atlassian manages encryption keys for Forge-hosted storage, and Nexus does not offer customer-managed or per-tenant keys. Each installation's storage is logically isolated by Atlassian. |
| EKM-03.1 | Do you encrypt tenant data at rest (on disk/storage) within your environment? | Yes (inherited) | Atlassian encrypts Forge-hosted storage (Forge SQL and KVS) and Jira data at rest with AES-256. Resync stores no customer data outside Atlassian. Secrets (AI provider key, migration credentials) are in Forge secret storage, and CI API keys are kept only as salted SHA-256 hashes. |
GRM — Governance and Risk Management
| ID | Question | Answer | Note |
|---|---|---|---|
| GRM-01.1 | Do you have documented information security baselines for every component of your infrastructure (e.g., hypervisors, operating systems, routers, DNS servers, etc.)? | Yes (inherited) | Atlassian sets the infrastructure baselines for Forge. Resync runs no hypervisors, operating systems or routers. The app-level baseline is documented and enforced: binding build rules, a supported Node runtime (nodejs24.x), a minimal CSP (styles only, no remote scripts, no unsafe-eval), and exact-host egress. |
| GRM-06.1 | Are your information security policies and procedures made available to all impacted personnel and business partners, authorized by accountable business role/function and supported by the information security management program as per industry best practices (e.g. ISO 27001, SOC 2)? | Partially | The engineering security policy (build rules, data-compatibility rules, security-fix SLA) is written, binding and enforced in CI. The customer-facing trust, privacy and DPA pages are published. There is no formal ISMS and no owner-approved information security policy aligned to ISO 27001 or SOC 2. |
| GRM-07.1 | Is a formal disciplinary or sanction policy established for employees who have violated security policies and procedures? | Yes | Employment agreements include a disciplinary process that covers breaches of security policy. |
| GRM-09.1 | Do you notify your tenants when you make material changes to your information security and/or privacy policies? | Yes | The privacy policy is dated, and significant changes are noted in the app release notes. The DPA commits to telling customers before adding a sub-processor, so they can object. Scope or egress changes can require a major version and administrator approval; the release mode and permission changes determine the requirements. |
| GRM-09.2 | Do you perform, at minimum, annual reviews to your privacy and security policies? | Yes | Resync reviews its privacy and security policies every October; first review October 2026. Policies were also reviewed repeatedly in 2026 before launch, and the build rules are re-checked every release. |
HRS — Human Resources
| ID | Question | Answer | Note |
|---|---|---|---|
| HRS-01.1 | Upon termination of contract or business relationship, are employees and business partners adequately informed of their obligations for returning organizationally-owned assets? | Yes | Everyone with access has signed a confidentiality agreement, and there is a documented joiner, mover and leaver process. When someone leaves or changes role, access is removed and company equipment is returned. |
| HRS-02.1 | Pursuant to local laws, regulations, ethics, and contractual constraints, are all employment candidates, contractors, and involved third parties subject to background verification? | Yes | Background checks are done before anyone is given access. |
| HRS-03.1 | Do your employment agreements incorporate provisions and/or terms in adherence to established information governance and security policies? | Yes | Everyone with access has signed a confidentiality agreement, and employment agreements include a disciplinary process covering breaches of security policy. DPA §4.2 commits Resync to bind authorised people to confidentiality. |
| HRS-04.1 | Are documented policies, procedures, and guidelines in place to govern change in employment and/or termination? | Yes | A documented joiner, mover and leaver process exists. Access is removed and company equipment is returned when someone leaves or changes role. |
| HRS-09.5 | Are personnel trained and provided with awareness programs at least once a year? | Yes | Security awareness training is done at least once a year for everyone with access. |
IAM — Identity & Access Management
| ID | Question | Answer | Note |
|---|---|---|---|
| IAM-01.1 | Do you restrict, log, and monitor access to your information security management systems (e.g., hypervisors, firewalls, vulnerability scanners, network sniffers, APIs, etc.)? | Yes | The management systems are the Atlassian developer console and Forge CLI, the private GitHub repository and its CI, the domain and DNS, and the support mailbox. Access is restricted to named Resync accounts, MFA is on for everyone on GitHub, the Atlassian developer console, Jira admin and the Marketplace partner account, and access is reviewed at least yearly. Atlassian and GitHub keep their own audit logs, and Resync reviews them monthly. There is no automated alerting. |
| IAM-01.2 | Do you monitor and log privileged access (e.g., administrator level) to information security management systems? | Yes | Atlassian and GitHub log administrative actions. Resync reviews Forge logs, the Atlassian developer console and the GitHub audit log for security events every month and at every release. There is no automated alerting. MFA is on for every administrator account. |
| IAM-02.1 | Do you have controls in place ensuring timely removal of systems access that is no longer required for business purposes? | Yes | In the product: CI API keys can be revoked at once, migration credentials are deleted after the run (30 days at most), and recurring runs re-check their creator's access every run. For Resync's own accounts, access is removed under the documented leaver process, and access is reviewed at least yearly with unneeded access removed. |
| IAM-04.1 | Do you manage and store the identity of all personnel who have access to the IT infrastructure, including their level of access? | Yes | Access goes through named accounts: Atlassian developer console contributors and GitHub organisation members. These platforms record each person's role. The source repository is private. |
| IAM-06.1 | Are controls in place to prevent unauthorized access to your application, program, or object source code, and assure it is restricted to authorized personnel only? | Yes | Source code is in a private GitHub repository, reached only through named accounts with MFA. CI workflows run with read-only tokens and persist-credentials: false, and deploy secrets are read only by a manual job. The Forge backend is built and signed by Atlassian on deploy. |
| IAM-06.2 | Are controls in place to prevent unauthorized access to tenant application, program, or object source code, and assure it is restricted to authorized personnel only? | N/A | Nexus does not host or run tenant application code. Customer test automation runs on the customer's own machines or CI. Anything a customer stores in Nexus, such as automation commands or AI script drafts, is ordinary Jira or Nexus data under the site's Jira permissions. |
| IAM-08.1 | Do you document how you grant, approve and enforce access restrictions to tenant/customer credentials following the rules of least privilege? | Yes | Documented and enforced in code: - Only Jira admins can connect or replace the AI provider key. It is held in Forge secret storage and never returned to the browser. - CI and ingestion keys are shown once, then stored only as a salted SHA-256 hash and compared in constant time. - Migration credentials are Forge secrets, deleted after use. CI service tokens are Forge secrets too: never returned to the browser, never logged, left out of backups, and deleted with the connection. - The Read test data permission on an API key is opt-in only and is never added to existing or new keys by default. - Nexus never collects Atlassian passwords or API tokens. - No credential or key is ever logged. |
| IAM-10.1 | Do you require a periodical authorization and validation (e.g. at least annually) of the entitlements for all system users and administrators (exclusive of users maintained by your tenants), based on the rule of least privilege, by business leadership or other accountable business role or function? | Yes | Access to GitHub, the Atlassian developer console, Jira admin and the Marketplace partner account is reviewed at least yearly, and unneeded access is removed. Product permissions always follow the customer's own Jira permissions, checked on the server for every request. |
| IAM-11.1 | Is timely deprovisioning, revocation, or modification of user access to the organizations systems, information assets, and data implemented upon any change in status of employees, contractors, customers, business partners, or involved third parties? | Yes | For Resync personnel: a documented leaver and role-change process removes access, and access is reviewed at least yearly. For customers' users: access always follows live Jira permissions, so removal in Jira takes effect immediately. Paused schedules re-check their creator. Closed Atlassian accounts are found through the Personal Data Reporting API and erased; the reporting integration is included in production 2.0.1, as it was in 2.0.0, with a default seven-day reporting cycle and resumable background processing. |
IVS — Infrastructure & Virtualization Security
| ID | Question | Answer | Note |
|---|---|---|---|
| IVS-01.1 | Are file integrity (host) and network intrusion detection (IDS) tools implemented to help facilitate timely detection, investigation by root cause analysis, and response to incidents? | Yes (inherited) | Resync runs no hosts or networks. Host and network monitoring for Forge compute and storage is Atlassian's (Forge SOC 2: logging, monitoring and alerting). The four Nexus webtriggers (results ingestion, CI API, automation runner and read API) authenticate each request with a per-project key and apply rate and size limits. |
| IVS-01.2 | Is physical and logical user access to audit logs restricted to authorized personnel? | Yes | Forge logs are visible only to the app's developer-console contributors and hold no End-User Data: no issue text, keys or account IDs, only fixed messages, error classes and opaque references. Every Nexus resolver checks Jira permissions as the calling user, on the server, before returning data, including audit history (build rule 14). |
| IVS-01.5 | Are audit logs reviewed on a regular basis for security events (e.g., with automated tools)? | Yes | Atlassian monitors the platform. Resync reviews Forge logs, the Atlassian developer console and the GitHub audit log for security events every month and at every release. There is no automated alerting. |
| IVS-03.1 | Do you use a synchronized time-service protocol (e.g., NTP) to ensure all systems have a common time reference? | Yes (inherited) | Forge compute and storage time sources are Atlassian-managed. Resync runs no servers. Webtrigger timestamps are checked against a ±5 minute window when clients send them. |
| IVS-07.1 | Are operating systems hardened to provide only the necessary ports, protocols, and services to meet business needs using technical controls (e.g., antivirus, file integrity monitoring, and logging) as part of their baseline build standard or template? | Yes (inherited) | Atlassian hardens the Forge runtime (vulnerability management and infrastructure hardening). Nexus runs on a supported, non-EOL Node runtime (nodejs24.x) and exposes four authenticated webtriggers. |
| IVS-08.1 | For your SaaS or PaaS offering, do you provide tenants with separate environments for production and test processes? | Yes | Nexus installs per Jira site, so a customer can install it on an Atlassian sandbox or a separate test site, and it is isolated from production. Resync keeps its own development and test sites separate from production. |
| IVS-08.3 | Do you logically and physically segregate production and non-production environments? | Yes | Forge development, staging and production are separate environments with separate installations and storage. Development and testing use Resync's own sites. Physical segregation is Atlassian's. |
| IVS-09.1 | Are system and network environments protected by a firewall or virtual firewall to ensure business and customer security requirements? | Yes (inherited) | Atlassian provides network security. Forge's outbound proxy also blocks every destination except the 19 exact hosts declared in the manifest (5 AI providers, 10 migration sources and 4 CI services, no wildcards). Custom UI runs behind Atlassian's CSP. |
| IVS-11.1 | Do you restrict personnel access to all hypervisor management functions or administrative consoles for systems hosting virtualized systems based on the principle of least privilege and supported through technical controls (e.g., two-factor authentication, audit trails, IP address filtering, firewalls and TLS-encapsulated communications to the administrative consoles)? | Yes (inherited) | Resync has no hypervisor or infrastructure console. Access control for Forge infrastructure is Atlassian's. Resync's only console is the Atlassian developer console, which has MFA on for everyone, is reviewed at least yearly and has its logs reviewed monthly. |
| IVS-12.1 | Are policies and procedures established and mechanisms configured and implemented to protect the wireless network environment perimeter and to restrict unauthorized wireless traffic? | N/A | No Resync network hosts the service or customer data. Nexus runs on Atlassian Forge, and data-centre networking is Atlassian's. |
| IVS-12.2 | Are policies and procedures established and mechanisms implemented to ensure wireless security settings are enabled with strong encryption for authentication and transmission, replacing vendor default settings (e.g., encryption keys, passwords, SNMP community strings)? | N/A | As IVS-12.1. |
| IVS-12.3 | Are policies and procedures established and mechanisms implemented to protect wireless network environments and detect the presence of unauthorized (rogue) network devices for a timely disconnect from the network? | N/A | As IVS-12.1. |
IPY — Interoperability & Portability
| ID | Question | Answer | Note |
|---|---|---|---|
| IPY-01.1 | Do you publish a list of all APIs available in the service and indicate which are standard and which are customized? | Yes | The Nexus CI and automation APIs (results ingestion, CI API and runner job queue) and the read-only API (the nexus-read-api web trigger, opt-in per key with the Read test data permission) are published on the docs site. Test-case issues and their Jira fields and properties are accessible through Jira APIs. Nexus also stores datasets, row values, step results and other app metadata in Forge storage. Use Nexus exports/backups or the supported, permission-controlled Nexus API for that data; a Jira export alone is not a complete Nexus backup. |
MOS — Mobile Security
| ID | Question | Answer | Note |
|---|---|---|---|
| MOS-03.1 | Do you have a policy enforcement capability (e.g., XACML) to ensure that only approved applications and those from approved application stores can be loaded onto a mobile device? | N/A | Nexus has no mobile app; it runs inside Jira. |
SEF — Security Incident Management, E-Discovery, & Cloud Forensics
| ID | Question | Answer | Note |
|---|---|---|---|
| SEF-02.1 | Do you have a documented security incident response plan? | No | Parts exist but there is no single written plan: a reporting contact, a commitment to notify customers without undue delay (DPA §6), the obligation to report to Atlassian through ECOHELP, and fix SLAs (Critical ≤5 business days, High ≤2 weeks, Medium ≤6 weeks, Low ≤12 weeks). |
| SEF-02.4 | Have you tested your security incident response plans in the last year? | No | There is no plan to test yet (see SEF-02.1). |
| SEF-03.1 | Are workforce personnel and external business relationships adequately informed of their responsibility, and, if required, consent and/or contractually required to report all information security events in a timely manner? | Yes | Everyone with access has signed a confidentiality agreement and does security awareness training at least yearly, and there is a documented reporting channel. Customers and researchers are told how to report: the privacy policy, DPA, trust page and support page all name nexus-support@resync.co.nz with "Security" in the subject. |
| SEF-03.2 | Do you have predefined communication channels for workforce personnel and external business partners to report incidents in a timely manner adhering to applicable legal, statutory, or regulatory compliance obligations? | Yes | Inbound reports go to nexus-support@resync.co.nz ("Security" subject, 24x7 "Urgent" contact, 24-hour first-response target). Outbound, customers are notified through their Marketplace technical and billing contacts, and Atlassian through ECOHELP. The security contact is registered on ecosystem.atlassian.net with the Security role on the Marketplace partner account (nexus-support@resync.co.nz, 10/10/2026), and no acknowledgement-time commitment is published. |
| SEF-04.4 | Do you enforce and attest to tenant data separation when producing data in response to legal subpoenas? | Yes (inherited) | Atlassian isolates each installation's Forge storage, and customer Jira data is per site. Resync holds no copy of customer data, so any legal request would be referred to the customer or Atlassian, and it could only ever concern one site. |
STA — Supply Chain Management, Transparency, and Accountability
| ID | Question | Answer | Note |
|---|---|---|---|
| STA-02.1 | Do you make security incident information available to all affected customers and providers periodically through electronic methods (e.g., portals)? | Partially | Affected customers are notified by email through their Marketplace contacts without undue delay, with updates as more is known (DPA §6). There is no status page or incident portal. Platform incidents appear on Atlassian's status page. |
| STA-03.1 | Do you collect capacity and use data for all relevant components of your cloud service offering? | Yes | Forge developer-console metrics cover invocations, errors and storage. Nexus enforces in-app storage budgets (for example, test data at 20 MB per project and 100 MB per site), counts AI tokens per site, and has a measured capacity model for about 500 concurrent testers (the Jira API points quota is the known limit). |
| STA-05.4 | Do third-party agreements include provision for the security and protection of information and assets? | Yes | The only sub-processor is Atlassian, under the Forge Developer Terms and the Forge Data Processing Addendum. AI providers, migration sources and CI services (GitHub Actions, GitLab.com, Azure DevOps Pipelines, Bitbucket Pipelines) are the customer's own accounts under the customer's agreements, not Resync sub-processors. Resync sends them nothing on its own behalf. |
| STA-05.5 | Do you have the capability to recover data for a specific customer in the case of a failure or data loss? | Yes | Per site: - A Jira admin can export and restore everything Nexus stores (Backup & Restore). Restores are hash-checked, and secrets are re-entered afterwards. - After an accidental uninstall, Resync can ask Atlassian to re-link that site's storage within 21 days, with the customer's consent. - Uninstalling Nexus does not delete your Jira issues. Nexus can permanently delete eligible issues when an authorised user explicitly requests supported deletion, import undo or sample-data removal. Jira permissions and the safeguards for that action apply. |
| STA-07.4 | Do you provide tenants with ongoing visibility and reporting of your operational Service Level Agreement (SLA) performance? | No | Resync publishes support hours (9am-5pm Monday-Friday NZ time), a 24-hour first-response target and security-fix SLAs, but no uptime SLA or SLA-performance reporting. Platform availability is shown on Atlassian's status page. |
| STA-09.1 | Do you mandate annual information security reviews and audits of your third party providers to ensure that all agreed upon security requirements are met? | Yes | The one sub-processor, Atlassian, is independently audited (Forge SOC 2 and ISO 27001). Every October Resync reviews Atlassian's security reports (SOC 2 and Forge trust materials); first review October 2026. |
TVM — Threat and Vulnerability Management
| ID | Question | Answer | Note |
|---|---|---|---|
| TVM-01.1 | Do you have anti-malware programs that support or connect to your cloud service offerings installed on all of your IT infrastructure network and systems components? | Yes | The service infrastructure is Atlassian's (vulnerability management under Forge SOC 2). Uploaded results files are parsed with external entities and DTDs refused. Work computers run anti-malware (Microsoft Defender). |
| TVM-02.5 | Do you have a capability to patch vulnerabilities across all of your computing devices, applications, and systems? | Yes | After an approved production deployment, Forge applies a minor update to installations running that same major version. Installations on another major need the relevant upgrade or a separately backported fix. A development deployment does not release a fix to customer production sites. For application changes, dependencies are audited on pull requests and pushes to main (fails at High); website-only changes are excluded, and the Node runtime is kept on a supported version. Security-fix SLAs: Critical ≤5 business days, High ≤2 weeks, Medium ≤6 weeks, Low ≤12 weeks, all inside Atlassian's minimums. Major upgrades may require administrator approval; the release mode and permission changes determine the upgrade requirements. Atlassian patches the platform; work computers install operating system updates automatically. |
| TVM-03.1 | Is mobile code authorized before its installation and use, and the code configuration checked, to ensure that the authorized mobile code operates according to a clearly defined security policy? | Yes | The only code in the browser is the Nexus Custom UI bundle, built from the reviewed repository and served by Atlassian. The CSP allows inline styles only: no remote scripts, no unsafe-eval, and no permissions.content.scripts. Downloadable helpers (CLI reporters and runner) ship with SHA-256 checksums and a release manifest tied to the tested commit. |
Appendix — questions only in the 74-question "v3.0.1" variant
These are worded as in that copy. Answer them only if a customer sends that variant.
| ID | Question | Answer | Note |
|---|---|---|---|
| AAC-03.2 | Do you have the capability to recover data for a specific customer in the case of a failure or data loss? | Yes | Same question as STA-05.5 in the main table. |
| BCR-09.1 | Do you provide tenants with ongoing visibility and reporting of your operational Service Level Agreement (SLA) performance? | No | Same question as STA-07.4. |
| BCR-11.4 | Have you implemented backup or redundancy mechanisms to ensure compliance with regulatory, statutory, contractual or business requirements? | Yes (inherited) | Same as BCR-11.3. |
| BCR-11.5 | Do you test your backup or redundancy mechanisms at least annually? | Yes | Same as BCR-11.7. Tested every October; first re-test October 2026. |
| CCC-01.2 | Is documentation available that describes the installation, configuration, and use of products/services/features? | Yes | Published docs: Get started, CI and API, automation and backup guides on nexus.resync.nz/docs/, plus in-app help. |
| DCS-01.1 | Do you maintain a complete inventory of all of your critical assets that includes ownership of the asset? | Yes | Same as DCS-01.2. |
| HRS-03.3 | Are all personnel required to sign NDA or Confidentiality Agreements as a condition of employment to protect customer/tenant information? | Yes | Everyone with access has signed a confidentiality agreement. DPA §4.2 commits Resync to bind authorised people to confidentiality. |
| HRS-03.5 | Are personnel trained and provided with awareness programs at least once a year? | Yes | Same as HRS-09.5. |
| TVM-03.2 | Is all unauthorized mobile code prevented from executing? | Yes | Atlassian's CSP for Custom UI blocks remote scripts and eval. Nexus declares only styles: unsafe-inline. |