Rainbook CAIQ Lite answers

These are Human Renaissance's answers to the Cloud Security Alliance's CAIQ v4 Lite questionnaire (CAIQ-Lite version 4.1.0, built on the Cloud Controls Matrix version 4.1), for Rainbook and Rainbook Mail Sync. The question IDs and wording are the Cloud Security Alliance's. Both apps run on Atlassian's cloud platform and keep your data in your Jira site and the Forge storage Atlassian hosts for it. Where a control belongs to that platform, such as data centres, hypervisors and networks, the answer says so and what Rainbook adds; Atlassian's own controls are on the Atlassian Trust Center. The trust centre and the security and privacy answers give the detail. For anything not covered here, write to security@rainbook.humanr.ai.

Audit & Assurance (A&A)

ID	Question	Answer
A&A-02.1	Are independent audit and assurance assessments conducted according to relevant standards at least annually?	No. Rainbook holds no SOC 2 or ISO 27001 certification of its own. It runs on Atlassian's certified cloud platform, whose audit reports are on the Atlassian Trust Center, and an independent penetration test of both apps runs in January and February 2027 through Atlassian's Marketplace Penetration Testing Program.
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. Human Renaissance has no audit plan of its own yet. An independent penetration test of both apps runs in January and February 2027 through Atlassian's Marketplace Penetration Testing Program, and its summary letter will be posted on the trust centre.
A&A-04.1	Is compliance verified regarding all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit?	Not applicable. Human Renaissance has no certification audit of its own; the platform's audits are Atlassian's (Atlassian Trust Center).
A&A-06.1	Is a risk-based corrective action plan to remediate audit findings established, documented, approved, communicated, applied, evaluated, and maintained?	Yes. Findings from the penetration test, Atlassian's scanning of Marketplace apps and researchers' reports are rated by severity and fixed within Atlassian's deadlines for cloud apps: critical within 10 days, high within 4 weeks, medium within 12 weeks and low within 25 weeks.
A&A-06.2	Is the remediation status of audit findings regularly reviewed and reported to relevant stakeholders?	Yes. We tell each reporter our plan and when the fix is live, and the penetration test's summary letter is posted on the trust centre when the test is complete.

Application & Interface Security (AIS)

ID	Question	Answer
AIS-02.1	Are baseline requirements to secure applications established, documented, and maintained?	Yes. Every request checks the caller, the licence and Jira permissions and refuses when a check can't complete, every read of the apps' own storage is filtered by Jira permissions and security levels, and database queries are parameterised. The trust centre lists these controls.
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?	No. Human Renaissance has no formal secure development lifecycle document. Changes are built in separate development environments and confirmed on our own test sites before they ship, and security issues are fixed within Atlassian's deadlines for cloud apps.
AIS-06.1	Are strategies and capabilities established and implemented to deploy application code in a secure, standardized, and compliant manner?	Yes. Both apps ship only through Atlassian Forge, as versioned releases built from the same code for every site, and only code deployed through Human Renaissance's Atlassian developer account reaches customer sites.
AIS-06.2	Is the deployment and integration of application code automated where possible?	Yes. A release reaches every site automatically as a minor version through Forge, with no manual step on customer sites.
AIS-07.1	Are application security vulnerabilities remediated following defined processes?	Yes. Our security policy sets the steps: acknowledge a report within two business days, confirm and rate it, and fix it within Atlassian's deadlines for cloud apps, critical within 10 days.
AIS-07.2	Is the remediation of application security vulnerabilities automated when possible?	Yes. Once a fix is ready it reaches every site automatically as a minor version, with nothing for customers to install.
AIS-08.1	Are processes, procedures, and technical measures defined and implemented to secure APIs?	Yes. Rainbook's one endpoint accepts only messages from Mail Sync signed with a per-site shared secret, Mail Sync's add-in endpoint accepts only per-person pairing tokens, and Rainbook's Rovo tools work under each person's Jira permissions.
AIS-08.2	Are reviews and updates for any improvements conducted at least annually, or upon significant changes?	Yes. Any change to the endpoints, permissions or outbound connections an app declares is published in the security answers in the same release.

Business Continuity Management and Operational Resilience (BCR)

ID	Question	Answer
BCR-01.1	Are business continuity management and operational resilience policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?	No. Human Renaissance has no separate business continuity policy; continuity of the hosting platform is Atlassian's (Atlassian Trust Center). Capture, AI and scheduled jobs can each be switched off while the rest of Rainbook keeps working, and nightly copies let Rainbook restore its own storage with at most one day lost.
BCR-01.2	Are the policies and procedures reviewed and updated at least annually, or upon significant changes?	No. There is no separate business continuity policy to review; the incident process is updated after every rehearsal and incident review.
BCR-02.1	Are criteria for developing business continuity and operational resiliency strategies and capabilities established based on business disruption and risk impacts?	No. There are no formal continuity criteria. Incidents are rated by impact, from Sev 1 (a security incident, data exposed or lost, or Rainbook unusable for a whole site) to Sev 3, and each severity sets our response time.
BCR-02.2	Are the risk assessment and impact analysis reviewed and updated at least annually or upon significant changes?	No. There is no formal risk assessment or impact analysis to review.
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. When Jira, Forge, Google or Microsoft is unavailable, the matching feature waits and resumes; capture, AI and scheduled jobs can each be switched off on their own; and every incident that stops Rainbook or a core job gets a written review within 5 business days, with what we change because of it.
BCR-08.1	Are backups performed periodically?	Yes. Records in Jira follow Atlassian's backups for your site, and every night Rainbook attaches a copy of its own storage to the Rainbook Archive work item: on paid sites the latest 7 daily, 4 weekly and 12 monthly copies.
BCR-08.2	Is the confidentiality, integrity, and availability of the backup ensured?	Yes. Copies are kept in your own Jira site and encrypted at rest by Atlassian, each copy is checked part by part before an older one is removed, and erased people are removed from copies within 30 days.
BCR-08.3	Can backups be restored appropriately for resiliency?	Yes. Admins restore Rainbook's storage from the newest copy with Restore this copy, its indexes are rebuilt from Jira within 8 business hours, and within 21 days of an uninstall Atlassian can reconnect both apps' storage on request; people who connected their own Google mailbox then reconnect it.
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. Human Renaissance has no disaster response plan of its own; recovery of the hosting platform from disasters is Atlassian's (Atlassian Trust Center). The nightly copies on the Rainbook Archive work item travel with your Jira backups.
BCR-09.2	Is the disaster response plan updated at least annually, and when significant changes occur?	No. There is no disaster response plan of our own to update.

Change Control and Configuration Management (CCC)

ID	Question	Answer
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?	No. There is no separate change management policy document. Changes are confirmed on our own test sites before they ship, and changes to an app's permissions or outbound connections are published in the security answers in the same release.
CCC-01.2	Are the policies and procedures reviewed and updated at least annually, or upon significant changes?	No. There is no change management policy document to review.
CCC-02.1	Is a defined quality change control, approval and testing process, incorporating baselines, testing, and release standards, established, maintained and implemented?	Yes. Every change is built in separate development environments and confirmed on Human Renaissance's own test sites before it ships, and each release goes out as a versioned Forge release.
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. Each app's permissions, outbound connections, storage and endpoints are declared in its manifest and published in the security answers, and a new subprocessor is announced at least 30 days before it receives data.
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. The data processing agreement limits us to your documented instructions: these terms, your admins' configuration and your users' actions. AI agents only propose changes, which a person who can edit the record applies, with Undo.
CCC-06.1	Are change management and configuration baselines established, documented and implemented for all relevant authorized changes on organizational assets?	Yes. Each app's manifest is its configuration baseline: its permissions, outbound connections, storage and endpoints, published as the data map in the security answers.
CCC-06.2	Are the baselines reviewed and updated at least annually or upon significant changes?	Yes. The baselines are checked on every release: the documents change in the same release as any product change to what the apps keep, and a release can't ship while a manifest's permissions or outbound addresses differ from the published data map.
CCC-07.1	Are detection measures implemented with proactive notification if changes deviate from established baselines?	Yes. The release checks stop any build whose manifest differs from the published data map, and Forge blocks any outbound address a manifest doesn't declare.
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. Capture, AI and scheduled jobs can each be switched off in a minor version that reaches every site at once, and records deleted in Rainbook and AI-proposed changes can be undone.

Cryptography, Encryption & Key Management (CEK)

ID	Question	Answer
CEK-01.1	Are cryptography, encryption, and key management policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?	No. Human Renaissance has no separate key management policy: Atlassian creates and manages the keys that encrypt Jira and Forge storage (Atlassian Trust Center). The secrets the apps hold are kept as encrypted Forge secrets and are never shown to anyone.
CEK-01.2	Are cryptography, encryption, and key management policies and procedures reviewed and updated at least annually, upon significant changes?	No. There is no key management policy of our own to review.
CEK-02.1	Are cryptography, encryption, and key management roles and responsibilities defined and implemented?	Yes. Atlassian creates and manages the keys that encrypt Jira and Forge storage; Mail Sync holds the mailbox tokens your admin grants, as encrypted Forge secrets that nobody can view; and Rainbook holds only the per-site shared secret for Mail Sync's signed messages.
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. Data at rest is encrypted with AES-256 and data in transit with TLS 1.2 or higher, both provided by Atlassian's platform under its own controls (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. AES-256 at rest and TLS 1.2 or higher in transit, for all customer data. Read Encryption at Rest.
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?	Not applicable. The encryption of storage and network traffic is Atlassian's, changed under Atlassian's own controls (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?	Not applicable. Atlassian generates and manages the keys that encrypt Jira and Forge storage (Atlassian Trust Center). The pairing tokens the apps create are random values kept as encrypted Forge secrets.
CEK-12.1	Are cryptographic keys rotated based on a cryptoperiod calculated while considering information disclosure risks and legal and regulatory requirements?	Not applicable. Rotation of storage encryption keys is Atlassian's control (Atlassian Trust Center). Mailbox tokens are revoked and deleted as soon as a mailbox is disconnected.
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. Mailbox tokens are deleted as soon as a mailbox is disconnected, and Google sign-in tokens are revoked with Google first. Storage encryption keys are Atlassian's control.
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. Mailbox tokens are deleted when a mailbox is disconnected, and Google sign-in tokens are revoked first. When you uninstall Rainbook Mail Sync, capture stops and Mail Sync revokes the Google sign-in tokens of people who connected their own Google mailbox, most recently used first. Atlassian deletes the app's Forge-hosted data 28 days after uninstall; a reinstall requested within 21 days can be relinked to that data. Storage encryption keys are Atlassian's control.

Datacenter Security (DCS)

ID	Question	Answer
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?	No. Human Renaissance has no written workplace security policy. Customer data stays in your Jira site and Atlassian's data centres, and staff have no standing access to customer data.
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?	No. There is no workplace security policy to review.
DCS-06.1	Is the classification and documentation of physical and logical assets based on the organizational business risk?	No. Assets aren't formally classified by business risk. The trust centre's data inventory lists every kind of customer data, where it lives and whether it stays after uninstall.
DCS-06.2	Are assets' classifications reviewed and updated at least annually or upon significant changes?	No. There is no formal asset classification to review; the data inventory itself is kept current, as the next answers describe.
DCS-07.1	Are all relevant physical and logical assets at all CSP sites cataloged and tracked within a secured system?	Yes. The physical assets are Atlassian's (Atlassian Trust Center). The logical ones are catalogued on the trust centre, which lists every place customer data lives, and in the security answers, which list each app's permissions, outbound connections, storage and endpoints.
DCS-07.2	Is the catalogue reviewed and updated at least annually or upon significant changes?	Yes. The catalogue changes with the product: the documents change in the same release as any product change to what the apps keep, and a release can't ship while a manifest's permissions or outbound addresses differ from the published data map.

Data Security and Privacy Lifecycle Management (DSP)

ID	Question	Answer
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. Data Handling, Data Retention, the privacy policy, the AI Usage Policy and the data processing agreement set out how data is collected, protected, kept and deleted.
DSP-01.2	Are data security and privacy policies and procedures reviewed and updated at least annually, or upon significant changes?	Yes. They are updated upon significant changes: the documents change in the same release as any product change to what the apps keep, and a release can't ship while a manifest's permissions or outbound addresses differ from the published data map. Material changes to the privacy policy are emailed to your licence's contacts before they apply.
DSP-03.1	Is a data inventory created and maintained for sensitive, regulated and personal information (at a minimum)?	Yes. The data inventory on the trust centre lists every field and store that holds personal data, where it lives and whether it stays after uninstall.
DSP-03.2	Is the inventory reviewed and updated at least annually or upon significant changes?	Yes. The inventory changes in the same release as any product change to what the apps keep.
DSP-04.1	Is data classified according to type and sensitivity levels?	No. Rainbook assigns no sensitivity levels of its own. Sensitive personal data is excluded by the end user terms, payment card and US Social Security numbers are masked wherever Rainbook writes text, and sites using Atlassian Guard data classification can classify the Activity space, where captured email lives.
DSP-05.1	Is data flow documentation created to identify what data is processed and where it is stored and transmitted?	Yes. The trust centre shows what is stored where, the Mail Sync architecture shows how mail moves into Jira, the AI Usage Policy lists what each AI feature sends, and the security answers list every outbound connection.
DSP-05.2	Is data flow documentation reviewed at defined intervals, at least annually, or upon significant changes?	Yes. The data flow pages are updated upon significant changes: the documents change in the same release as any product change to what the apps keep, and a release can't ship while a manifest's permissions or outbound addresses differ from the published data map.
DSP-06.1	Is the ownership and stewardship of all relevant personal and sensitive data documented?	Yes. Your organisation is the controller of the data it keeps in the apps, Human Renaissance Corporation is its processor, and Atlassian hosts the apps as our subprocessor, as the data processing agreement sets out.
DSP-06.2	Is data ownership and stewardship documentation reviewed at least annually?	No. There is no fixed annual review; the data processing agreement and privacy policy are updated, and material changes emailed, whenever roles change.
DSP-07.1	Are systems, products, and business practices based on security principles by design and per industry best practices?	Yes. Both apps keep data only in your Jira site and Atlassian's Forge storage, every read checks Jira permissions, Mail Sync reads mail with read-only permissions, and app logs carry no names, email addresses or content.
DSP-08.1	Are systems, products, and business practices based on privacy principles by design and according to industry best practices?	Yes. Usage analytics, error reports and app logs never carry names, email addresses, record content or prompts; AI requests carry only what the request needs and the person can see; and the people index is capped and pruned.
DSP-08.2	Are systems' privacy settings configured by default and according to all applicable laws and regulations?	Yes. Masking of card and Social Security numbers, minimised logs and permission-filtered reads are on by default. Usage analytics and error reports are also on by default, carry no names, email addresses or record content, and admins switch them off in Atlassian's admin controls.
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. All traffic uses TLS 1.2 or higher, Mail Sync writes mail straight to your Jira site with nothing copied elsewhere on the way, and transfers out of the EEA or UK are covered by the EU Standard Contractual Clauses and the UK addendum in the data processing agreement.
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. Admins export everything held about a person, or erase them, by email address, including people who never used Rainbook, and can stop future capture of that address.
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. The data processing agreement sets the purpose of processing, Google data is used only under Google's Limited Use requirements, and your data isn't used to train models, sold or used for advertising.
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. Each subprocessor is bound to data protection terms no less protective than our data processing agreement, with the Standard Contractual Clauses between us and our subprocessors where data leaves the EEA or UK.
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. The subprocessor list shows what each service receives, a new subprocessor is announced at least 30 days before it receives data, and optional services receive nothing until your admin turns each one on.
DSP-16.1	Do data retention, archiving, and deletion practices follow business requirements, applicable laws, and regulations?	Yes. Data Retention sets how long each kind of data is kept: deleted records and AI traces for 30 days, app logs for 30 days, Ask history for 13 months from last use. Admins erase any person on request.
DSP-17.1	Are processes, procedures, and technical measures defined and implemented to protect sensitive data throughout its lifecycle?	Yes. The end user terms exclude sensitive personal data, and payment card and US Social Security numbers are masked wherever Rainbook writes text. Attached files, file names, images and text typed directly in Jira's own screens are not scanned.
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. Rainbook stores your data in your Jira site's data residency region, AI requests run in Atlassian's published Forge LLM regions, and Mail Sync reads mail from your own Google Workspace or Microsoft 365 tenant. The subprocessor list names every other service.

Governance, Risk and Compliance (GRC)

ID	Question	Answer
GRC-01.1	Are information governance program policies and procedures sponsored by organizational leadership established, documented, approved, communicated, applied, evaluated, and maintained?	No. Human Renaissance has no formal information governance programme. Our security and privacy commitments are published on the trust centre, the security policy and the data processing agreement.
GRC-01.2	Are the policies and procedures reviewed and updated at least annually, or upon significant changes?	No. There is no programme review on a schedule; the published documents change in the same release as any product change to what the apps keep.
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. Human Renaissance has no formal enterprise risk management programme.
GRC-06.1	Are roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs defined and documented?	No. There is no formal governance programme with defined roles. Every incident has one named incident lead.
GRC-07.1	Are all relevant standards, regulations, legal/contractual, and statutory requirements applicable to your organization identified and documented?	Yes. The requirements that apply are written into our terms: GDPR through the data processing agreement, with the EU Standard Contractual Clauses and the UK addendum; the CCPA in the privacy policy; Google's Limited Use requirements; and Atlassian's Marketplace terms and security deadlines for cloud apps.
GRC-07.2	Are the identified requirements reviewed at least annually or upon significant changes?	No. There is no scheduled review of these requirements; the terms are updated when they change, and material changes are emailed to your licence's contacts before they apply.

Human Resources (HRS)

ID	Question	Answer
HRS-03.1	Are policies and procedures requiring unattended workspaces to conceal confidential data established, documented, approved, communicated, applied, evaluated, and maintained?	No. Human Renaissance has no written clean desk policy. Staff have no standing access to customer data, so it isn't kept in our workspaces.
HRS-03.2	Are policies and procedures requiring unattended workspaces to conceal confidential data reviewed and updated at least annually, or upon significant changes?	No. There is no clean desk policy to review.
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. Human Renaissance has no written remote working policy. Staff reach the apps only through Atlassian over TLS 1.2 or higher, have no standing access to customer data, and work from the diagnostics an admin chooses to share.
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. There is no remote working policy to review.
HRS-11.1	Is a security awareness training program for all employees of the organization established, documented, approved, communicated, applied, evaluated and maintained?	No. There is no formal security awareness training programme. The team rehearses the incident process with tabletop exercises, one on data exposure and one on a capture outage.
HRS-11.2	Are regular security awareness training updates provided?	No. There are no scheduled training updates; the incident process is updated after every rehearsal and incident review.

Identity & Access Management (IAM)

ID	Question	Answer
IAM-01.1	Are identity and access management policies and procedures established, documented, approved, communicated, implemented, applied, evaluated, and maintained?	Yes. Access to customer data follows Jira's permissions, set out on the trust centre under Who sees what, and staff access is limited to the diagnostics an admin chooses to share or a Jira user the admin invites for a limited time.
IAM-01.2	Are identity and access management policies and procedures reviewed and updated at least annually, or upon significant changes?	Yes. The access rules are updated upon significant changes: the trust centre changes in the same release as any product change to who sees what.
IAM-03.1	Is the inventory of identities managed, stored, and regularly reviewed, and is their level of access monitored?	Yes. People reach the apps with Atlassian accounts your organisation manages, Rainbook reports the account IDs it stores to Atlassian each week and clears closed accounts, and admin actions are recorded in the activity history.
IAM-04.1	Is the separation of duties principle employed when implementing information system access?	Yes. The two apps share no storage and accept only signed messages from each other, Mail Sync alone holds mailbox tokens, and AI agents only propose changes that a person who can edit the record applies.
IAM-05.1	Is the least privilege principle employed when implementing information system access?	Yes. Mail Sync reads mail and calendars with read-only permissions and can be limited to chosen mailboxes, each person and the AI see only what Jira lets that person see, and staff have no standing access to customer data.
IAM-06.1	Is an identity access provisioning process defined and implemented which authorizes, records, and communicates data and assets access changes?	Yes. Access comes from the Jira permissions and groups your organisation manages, your Jira admins run Rainbook's settings and only members of the rainbook-admins group reach record content (imports, activity history, exports, privacy requests), both checked live on every admin action, and admin changes such as AI settings and diagnostics shares are recorded in the activity history.
IAM-07.1	Is a process in place to de-provision or modify identity access in a timely manner?	Yes. Every request checks Jira permissions, so a change to your Jira groups applies on the next request; accounts closed in Atlassian are cleared each week; a disconnected mailbox's token is revoked at once; and your admin removes a support user when the work is done.
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. Human Renaissance doesn't run periodic access reviews. Staff have no standing access to customer data, and Rainbook admin rights are checked live on every admin action, so a change in your Jira admins or groups applies at once.
IAM-09.1	Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated?	Yes. Rainbook settings belong to your Jira admins, and record-content admin work to members of the rainbook-admins group, both separate from ordinary users and checked live on every admin action. Only admins change AI settings, and only rainbook-admins members share diagnostics or erase a person.
IAM-10.1	Is an access process defined and implemented to ensure privileged access roles and rights are granted for a limited period?	Yes. Human Renaissance's only route into a customer site is a Jira user your admin invites for a limited time and removes when the work is done; staff hold no standing access.
IAM-10.2	Are procedures implemented to prevent the accumulation of segregated privileged access?	Yes. Staff hold no standing access, so none accumulates: support access is invited for one request and removed afterwards.
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. Everyone signs in through Atlassian, so the sign-in rules your organisation sets in Atlassian, including two-step verification, apply; the apps store no passwords; and the inbox add-ins use per-person pairing tokens.
IAM-13.2	Are digital certificates or alternatives that achieve an equivalent security level for system identities adopted?	Yes. Connections use TLS certificates, messages between the two apps are signed with a per-site shared secret, and the inbox add-ins authenticate with per-person pairing tokens.

Interoperability & Portability (IPY)

ID	Question	Answer
IPY-01.1	Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for communications between application interfaces (e.g., APIs)?	Yes. The security answers list every endpoint both apps expose and how each is authenticated: Rainbook's accepts signed messages from Mail Sync only, and Mail Sync's serves the inbox add-ins and the mailbox sign-in.
IPY-01.2	Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information processing interoperability?	Yes. Your records are standard Jira work items, so Jira's search, permissions, automation and export work on them, and Rainbook's Rovo tools are reachable through Atlassian's MCP server under each person's Jira permissions.
IPY-01.3	Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for application development portability?	Not applicable. Rainbook is a finished application, not a platform customers build applications on.
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. Records, captured email and files stay in Jira as work items even after uninstall, Download all data saves everything Rainbook keeps outside them, activity history exports as CSV, and a person's data exports as a ZIP.
IPY-01.5	Are interoperability and portability policies and procedures reviewed and updated at least annually, or upon significant changes?	Yes. These pages are updated upon significant changes, in the same release as any change to the apps' endpoints or exports.

Infrastructure Security (I&S)

ID	Question	Answer
I&S-03.1	Are communications between environments, services, and applications monitored?	Not applicable. Network traffic monitoring is Atlassian's control (Atlassian Trust Center). For the apps, alerts on each app's errors, timeouts and failed jobs reach our on-call phone around the clock.
I&S-03.2	Are communications between environments, services, and applications encrypted?	Yes. Every connection between your browser, Jira, both apps, Google and Microsoft uses TLS 1.2 or higher, and rainbook.humanr.ai is served only over HTTPS with HTTP Strict Transport Security.
I&S-03.3	Are communications between environments, services, and applications restricted to only authenticated and authorized connections, as justified by the business?	Yes. Every request checks the caller, the licence and Jira permissions; the apps' endpoints accept only signed messages or per-person pairing tokens; and Forge lets each app reach only the outbound addresses its manifest declares.
I&S-03.4	Are network configurations reviewed at least annually?	Not applicable. The network is Atlassian's, under Atlassian's controls (Atlassian Trust Center). The apps' own outbound connections are checked on every release against the published data map.
I&S-03.5	Are network configurations supported by the documented justification of all allowed services, protocols, ports, and compensating controls?	Yes. Every permission and outbound address each app uses is declared in its manifest and listed, with what it is for, in the security answers and the subprocessor list. Ports and protocols of the hosting network are Atlassian's.
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?	Not applicable. Rainbook runs no operating systems, hypervisors or control planes of its own: both apps run in Atlassian's Forge sandbox, on infrastructure Atlassian hardens (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. Atlassian's Forge platform isolates each Jira site's data, a request for one site never reads another site's data, and anything Rainbook keeps in memory is kept per site.
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. Every connection the apps use, imports included, runs over TLS 1.2 or higher, and moves of a site's data between data residency locations are made by Atlassian's platform.
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?	Not applicable. Network defence is Atlassian's control (Atlassian Trust Center). On top of it, Forge lets each app reach only the outbound addresses its manifest declares.

Logging and Monitoring (LOG)

ID	Question	Answer
LOG-01.1	Are logging and monitoring policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?	Yes. Data Handling sets what app logs hold (account IDs, the cloud ID, site host and record keys only), that they are kept for 30 days in Atlassian's Forge logs, and who can read them. The activity history records who changed what and when.
LOG-01.2	Are policies and procedures reviewed and updated at least annually, or upon significant changes?	Yes. Data Handling is updated upon significant changes, in the same release as any product change to what the apps log or keep.
LOG-04.1	Is audit log access restricted to authorized identities, and are records of that access maintained?	No. Access is restricted: Human Renaissance engineers read app logs only on sites that share them with app developers, which your admins can turn off. Records of who read the logs are not part of our controls.
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. Human Renaissance runs no security log correlation. Automated alerts on each app's errors, timeouts and failed jobs reach our on-call phone around the clock, and Atlassian scans Marketplace apps for security issues.
LOG-05.2	Is a process established and followed to review and take appropriate and timely actions on detected anomalies?	Yes. An alert or report that points to a security problem opens an incident with a severity and one incident lead, then containment, the fix and a written review, as Incident Response sets out.
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. App logs never hold names, email addresses, subjects, bodies, file names, field values, prompts or AI output; error reports carry a scrambled site ID only; card and Social Security numbers are masked in captured and logged email; and erasing a person replaces them with "[erased]" in the activity history.

Security Incident Management, E-Discovery, & Cloud Forensics (SEF)

ID	Question	Answer
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. The Incident Response process names one incident lead, posts a Sev 1 on the status page within 1 hour, emails affected sites' technical contacts within 72 hours of confirming an incident that affects their data, and reports every security incident to Atlassian within 24 hours.
SEF-04.1	Is a structured approach followed to evaluate the effectiveness of incident response plans at planned intervals or upon significant changes?	Yes. We rehearse the incident process with tabletop exercises, one on data exposure and one on a capture outage, and every incident that stops Rainbook or a core job gets a written review within 5 business days.
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. Each incident gets a severity with its own response time: Sev 1 within 2 hours around the clock with updates every 6 hours, Sev 2 within 8 business hours, Sev 3 within 1 business day.
SEF-07.2	Are these processes and procedures reviewed, updated, and tested at least annually?	Yes. The process is tested with tabletop exercises and updated from each exercise and each incident review.
SEF-08.1	Are processes, procedures, and technical measures for security breach notifications defined and implemented?	Yes. The data processing agreement sets breach notice: without undue delay, and within 72 hours of confirming a personal data breach, with its nature, the data and people concerned, likely consequences and what we are doing.
SEF-08.2	Are material security breaches reported (including any relevant supply chain breaches) as per applicable SLAs, laws, and regulations?	Yes. We tell affected customers within 72 hours of confirming an incident that affects their data and report every security incident to Atlassian within 24 hours.

Supply Chain Management, Transparency, and Accountability (STA)

ID	Question	Answer
STA-01.1	Are policies and procedures for supply chain risk management established, documented, approved, communicated, applied, evaluated, and maintained?	No. Human Renaissance has no formal supply chain risk policy. Each subprocessor is bound to data protection terms no less protective than our data processing agreement, and the analytics and error-report services receive no names, email addresses or record content.
STA-01.2	Are policies and procedures for supply chain risk management reviewed and updated at least annually, or upon significant changes?	No. There is no supply chain risk policy to review; the subprocessor list is kept current, with 30 days' notice of changes.
STA-03.1	Is the SSRM applied, documented, implemented, and managed throughout the supply chain?	Yes. This page marks which controls are Atlassian's and which are ours, the data processing agreement names Atlassian as our subprocessor for the Forge platform's controls, and the subprocessor list says what each other service receives.
STA-05.1	Is the shared ownership and applicability of all CSA CCM controls delineated according to the SSRM?	Yes. For the controls on this page, each answer says whether the control is Atlassian's, Human Renaissance's or your admins'.
STA-08.1	Is an inventory of all supply chain relationships developed and maintained?	Yes. The subprocessor list names every service that processes data for the apps and what each receives.

Threat & Vulnerability Management (TVM)

ID	Question	Answer
TVM-02.1	Are policies and procedures to protect against malware and malicious instructions established, documented, approved, communicated, applied, evaluated, and maintained?	No. Human Renaissance has no written anti-malware policy. The apps run in Atlassian's Forge sandbox under Atlassian's content security policy, on infrastructure Atlassian protects (Atlassian Trust Center).
TVM-02.2	Are asset management and malware protection policies and procedures reviewed and updated at least annually, or upon significant changes?	No. There is no anti-malware policy to review.
TVM-03.1	Are processes, procedures, and technical measures defined, implemented, and evaluated for vulnerability detection on organizationally managed assets at least monthly?	No. Human Renaissance runs no monthly vulnerability scan of its own. Atlassian scans Marketplace apps for security issues, researchers report to security@rainbook.humanr.ai, and an independent penetration test of both apps runs in January and February 2027 through Atlassian's Marketplace Penetration Testing Program.
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?	No. Human Renaissance runs no detection tools with signature updates; the apps run in Atlassian's Forge sandbox, on infrastructure Atlassian protects.
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. Vulnerabilities are fixed by severity within Atlassian's deadlines for cloud apps, critical within 10 days, and in an emergency capture, AI or scheduled jobs can be switched off at once in a minor version that reaches every site.
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. Each issue is rated by severity and fixed within the deadlines of Atlassian's security bug-fix policy for cloud apps.
TVM-11.1	Is a process defined and implemented to track and report vulnerability identification and remediation activities that include stakeholder notification?	Yes. Each report is tracked from acknowledgement to fix; we tell the reporter our plan and when the fix is live, and affected customers hear through our incident process.

Universal Endpoint Management (UEM)

ID	Question	Answer
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. Human Renaissance keeps no approved-application list for endpoints. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.
UEM-04.1	Is an inventory of all endpoints used and maintained to store, access and process company data?	No. Human Renaissance keeps no endpoint inventory. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.
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?	No. Human Renaissance doesn't run endpoint management. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.
UEM-06.1	Are all relevant interactive-use endpoints configured to require an automatic lock screen?	No. No written endpoint policy requires it. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.
UEM-09.1	Are anti-malware detection and prevention technology services configured on managed endpoints?	No. Human Renaissance doesn't manage endpoints centrally. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.
UEM-10.1	Are software firewalls configured on managed endpoints?	No. Human Renaissance doesn't manage endpoints centrally. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.
UEM-13.1	Are processes, procedures, and technical measures defined, implemented, and evaluated to enable remote company data deletion on managed endpoint devices?	No. Human Renaissance doesn't manage endpoints centrally, so there is no remote wipe. The apps store no customer data on phones or laptops: the Gmail and Outlook add-ins keep only a pairing token. Staff have no standing access to customer data.