CAIQ Lite Self-Assessment

Are independent audit and assurance assessments conducted according to relevant standards at least annually?

Implementation: Sync-o is a small Italian sole-proprietorship vendor and does not currently undergo independent third-party security audits (SOC 2, ISO 27001) due to cost being disproportionate to company scale. Sync-o inherits AWS's audited controls (SOC 2 / ISO 27001 / PCI DSS) for its underlying infrastructure (AWS Ireland eu-west-1), Atlassian Forge's audited platform controls for the application surface, and Google Cloud's audited controls (SOC 2 / ISO 27001) for AI processing. Sync-o performs annual internal self-assessments against this CAIQ Lite and against the published CCM controls.

Customer Responsibilities: Customers may review the published Sync-o DPA (sync-o.io/dpa), Privacy Policy, and Trust Center, and the audit certifications of the underlying providers (AWS, Atlassian, Google Cloud).

Are independent audit and assurance assessments performed according to risk-based plans and policies?

Implementation: No third-party audits performed. Internal annual self-assessment follows a risk-based scope focused on data-handling, IAM, and encryption — the highest-risk areas for Sync-o's data model.

Is compliance verified regarding all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit?

Implementation: Sync-o tracks GDPR (Italian + EU jurisdiction), Atlassian Marketplace Cloud App Privacy and Security Requirements, and Forge platform compliance requirements. Internal annual review confirms continued adherence; deltas trigger code or policy updates documented in the project paper and DPA.

Is a risk-based corrective action plan to remediate audit findings established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: When self-assessment or external feedback identifies a control gap, a tracking entry is opened in the project tracker, prioritized by risk impact (data exposure > availability > policy gaps), and resolved with code changes, documentation updates, or process changes. Remediation is recorded in Git commit history and the project paper.

Is the remediation status of audit findings reviewed and reported to relevant stakeholders?

Implementation: Material remediations (security-relevant) are disclosed in the public changelog at sync-o.io/changelog and to affected customers via [email protected] when applicable.

Are baseline requirements to secure different applications established, documented, and maintained?

Implementation: Sync-o follows OWASP Top 10 and Atlassian Forge security best practices as baseline. The Forge platform enforces sandbox isolation, scoped permissions, and CSP-by-default. The AWS Lambda backend follows least-privilege IAM, encrypted-at-rest storage (KMS AES-256), and TLS-only ingress.

Is an SDLC process defined and implemented for application design, development, deployment, and operation per organizationally designed security requirements?

Implementation: All code changes flow through a private GitHub repository workflow: branch → pull request → static analysis (CodeQL) and dependency scanning (Dependabot, pip-audit, npm audit) → manual review → merge → automated deploy via Forge CLI (frontend) or aws lambda update-function-code (backend). Forge platform validates manifest scopes before deploy.

Are strategies and capabilities established and implemented to deploy application code in a secure, standardized, and compliant manner?

Implementation: Standardized deploy pipeline: forge deploy -e production for the Forge frontend (Atlassian-managed); aws lambda update-function-code for the AWS backend Python Lambdas in eu-west-1. Forge enforces signed manifests; AWS IAM restricts deploy permissions to authorized operators.

Is the deployment and integration of application code automated where possible?

Implementation: Forge frontend deploys via a single forge deploy command. AWS backend deploys via scripted aws lambda update-function-code commands. CI dependency scanning is automated on push.

Are application security vulnerabilities remediated following defined processes?

Implementation: GitHub Dependabot auto-PRs updates for vulnerable npm and pip dependencies. CodeQL flags newly-discovered SAST issues on each PR. Severity-based SLA: critical (CVSS 9+) same-day patch+deploy; high (7-8.9) within 14 days; medium/low within 30-90 days.

Is the remediation of application security vulnerabilities automated when possible?

Implementation: Dependabot generates automatic remediation pull requests for vulnerable dependencies. Merge + redeploy is gated by manual review.

Are business continuity management and operational resilience policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: Sync-o relies on AWS eu-west-1 multi-AZ resilience (Lambda, DynamoDB, SQS all multi-AZ by default). The Atlassian Forge platform provides additional fail-over for the frontend. Sync-o's data model is fundamentally stateless (full content fetched on demand) with persisted state limited to DynamoDB metadata + short content excerpts, all backed by PITR.

Are the policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed. Reviews captured in the project paper's version history.

Are criteria for developing business continuity and operational resiliency strategies and capabilities established based on business disruption and risk impacts?

Implementation: Risk model prioritizes data integrity > availability > confidentiality. AWS eu-west-1 multi-AZ covers single-AZ failure. Regional failure would require manual recovery (acknowledged residual risk for a small vendor; historical AWS regional outages last hours, not days).

Are strategies developed to reduce the impact of, withstand, and recover from business disruptions in accordance with risk appetite?

Implementation: DynamoDB Point-in-Time Recovery (PITR) enabled on all Sync-o tables. Lambda code stored in versioned GitHub. Forge frontend can be re-deployed in minutes from source. Vector data has 90-day TTL and is regeneratable by triggering ticket transitions.

Is cloud data periodically backed up?

Implementation: DynamoDB Point-in-Time Recovery (35-day window) plus DeletionProtection enabled on all Sync-o tables. CloudWatch logs retained per default policy. GitHub holds all code and configuration.

Is the confidentiality, integrity, and availability of backup data ensured?

Implementation: DynamoDB PITR uses AWS-managed encryption (AES-256 KMS) and inherits AWS's 11-nines durability. Access to restore operations is restricted to the operator IAM principal protected by MFA.

Can backups be restored appropriately for resiliency?

Implementation: DynamoDB PITR restore has been exercised in production (May 2026 incident — recovered a 537-item tenant table successfully). Procedure documented in the project paper.

Is a disaster response plan established, documented, approved, applied, evaluated, and maintained to ensure recovery from natural and man-made disasters?

Implementation: Disaster response procedure: (1) AWS regional outage → wait for AWS recovery; (2) DynamoDB data corruption → PITR restore; (3) Atlassian Forge platform outage → wait for Atlassian; (4) Operator unavailable → owner has standing access to AWS, GitHub, and Atlassian. Target RTO 24h, RPO 35 days (PITR window).

Is the disaster response plan updated at least annually, and when significant changes occur?

Implementation: Annual review committed. Plan was last updated for the OpenSearch → DynamoDB vector migration in May 2026.

Are risk management policies and procedures associated with changing organizational assets including applications, systems, infrastructure, configuration, etc., established, documented, approved, communicated, applied, evaluated and maintained (regardless of whether asset management is internal or external)?

Implementation: All changes (code, infra, configuration) flow through Git: feature branch → PR → CI checks (CodeQL, Dependabot, pip-audit) → manual review → merge to main → deploy. Forge CLI requires explicit -e production flag; AWS Lambda deploys require IAM-authenticated CLI calls. Rollback is a git revert + redeploy.

Are the policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed. Changes captured in the project paper.

Is a defined quality change control, approval and testing process (with established baselines, testing, and release standards) followed?

Implementation: Each significant change is tested in a dev tenant (sync-o-dev.atlassian.net) before production. AWS Lambda has rapid rollback via aws lambda update-function-code with the prior zip artifact. Forge has standard version-pinning and rollback via environments.

Is the unauthorized addition, removal, update, and management of organization assets restricted?

Implementation: AWS account access is gated by hardware MFA on root and operator IAM. GitHub repositories require MFA on every push. Forge deploys are bound to authenticated Atlassian accounts.

Are provisions to limit changes that directly impact CSC-owned environments and require tenants to authorize requests explicitly included within the service level agreements (SLAs) between CSPs and CSCs?

Implementation: Sync-o is delivered via Atlassian Forge — Atlassian Marketplace's published Cloud App Developer Terms govern install-time consent. Changes requiring additional scopes prompt re-authorization through the Atlassian platform. Material data-handling changes are reflected in DPA version bumps + listing description updates.

Customer Responsibilities: Customers receive scope-change prompts at upgrade and can decline. Customers may uninstall at any time, triggering immediate deletion of all tenant data.

Are change management baselines established for all relevant authorized changes on organizational assets?

Implementation: Baseline = main branch HEAD on GitHub. Production state = the currently-deployed Forge version + AWS Lambda CodeSha256 (visible via AWS console). Any mismatch triggers investigation.

Are detection measures implemented with proactive notification if changes deviate from established baselines?

Implementation: Forge platform reports the installed app version; AWS reports Lambda CodeSha256. Both can be compared against the expected build hash from CI. CloudWatch Alarms fire on unexpected Lambda error-rate spikes.

Is a process to proactively roll back changes to a previously known "good state" defined and implemented in case of errors or security concerns?

Implementation: Forge: forge install --version <prior-version>. AWS Lambda: aws lambda update-function-code with the prior versioned zip artifact. DynamoDB: PITR restore.

Are cryptography, encryption, and key management policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: Policy: TLS 1.2+ for all data in transit; AES-256 (AWS KMS-managed keys) for all data at rest in DynamoDB; Forge setSecret (Atlassian-managed encryption) for customer-supplied tokens like AI API keys. No customer-managed keys offered or required.

Are cryptography, encryption, and key management policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed.

Are cryptography, encryption, and key management roles and responsibilities defined and implemented?

Implementation: Key lifecycle (creation, rotation, revocation, destruction) is fully managed by AWS KMS (DynamoDB at-rest) and Atlassian Forge platform (setSecret). Sync-o configures encryption mode but never holds key material directly.

Are data at-rest and in-transit cryptographically protected using cryptographic libraries certified to approved standards?

Implementation: At rest: AWS KMS AES-256 (FIPS 140-2 validated cryptographic modules). In transit: TLS 1.2+ enforced on all endpoints (AWS-managed certs via ACM; Atlassian-managed certs on Forge). All AI provider connections (Vertex, OpenAI, Anthropic, Azure OpenAI) use TLS 1.2+.

Are appropriate data protection encryption algorithms used that consider data classification, associated risks, and encryption technology usability?

Implementation: AES-256-GCM (AWS KMS) and modern TLS 1.2+ cipher suites (AWS / Atlassian managed). All algorithms meet NIST and ENISA recommendations for sensitive but non-classified data.

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?

Implementation: Encryption technology changes flow through the same Git PR + review process as all other code changes. Updates to underlying AWS/Atlassian crypto stacks are inherited automatically per providers' service updates.

Are cryptographic keys generated using industry-accepted and approved cryptographic libraries that specify algorithm strength and random number generator specifications?

Implementation: All cryptographic keys are generated by AWS KMS (FIPS 140-2 Level 2 HSM-backed) and the Atlassian Forge setSecret backend. Sync-o does not generate keys directly.

Are cryptographic keys rotated based on a cryptoperiod calculated while considering information disclosure risks and legal and regulatory requirements?

Implementation: AWS KMS managed keys rotate annually by default. Customer-supplied AI API keys are rotated by the customer via Settings → AI Provider when they wish; revoking the token in their provider account immediately invalidates Sync-o's access regardless of our cached copy.

Customer Responsibilities: Customers may rotate their BYOM API keys at any time via Settings → AI Provider.

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?

Implementation: Customer-supplied keys: revoked immediately by the customer in their provider account; Sync-o's stored copy becomes inert. Sync-o removes the encrypted token from DynamoDB on customer request or app uninstall. AWS KMS keys revoked via AWS Console if compromise is suspected.

Customer Responsibilities: Customers may revoke their AI provider keys directly with the provider at any time; should report any suspected compromise to [email protected].

Are processes, procedures and technical measures to destroy unneeded keys defined, implemented and evaluated to address key destruction outside secure environments, revocation of keys stored in hardware security modules (HSMs), and include applicable legal and regulatory requirement provisions?

Implementation: On app uninstall, all encrypted tokens are deleted from DynamoDB via the Forge uninstall webhook handler. AWS KMS key deletion follows the standard 30-day pending-deletion window per AWS KMS policy.

Are policies and procedures for maintaining a safe and secure working environment (in offices, rooms, and facilities) established, documented, approved, communicated, enforced, and maintained?

Implementation: Sync-o operates entirely from cloud infrastructure (AWS eu-west-1 datacenters, Atlassian Forge platform, Google Cloud Belgium). Sync-o maintains no physical office, server room, or datacenter. All physical security controls are inherited from AWS, Atlassian, and Google Cloud — each independently audited under SOC 2, ISO 27001, and equivalent frameworks.

Are policies and procedures for maintaining safe, secure working environments (e.g., offices, rooms) reviewed and updated at least annually?

Implementation: Not applicable — no physical environment under Sync-o's direct management.

Is the classification and documentation of physical and logical assets based on the organizational business risk?

Implementation: Logical assets only (no physical). Inventory: AWS resources (Lambdas, DynamoDB tables, SQS queues — listed in template.yaml and project paper); Forge app entities (resolvers, triggers — declared in manifest.yml); GitHub repositories. All classified as 'tenant data' (highest sensitivity) or 'operational' (medium).

Are all relevant physical and logical assets at all CSP sites cataloged and tracked within a secured system?

Implementation: AWS resources inventoried via template.yaml + AWS Resource Tagging. Forge entities inventoried in manifest.yml. The project paper (DOCUMENTATION/Sync-O-Project-Paper.md) is the authoritative system catalog and is version-controlled.

Are policies and procedures established, documented, approved, communicated, enforced, evaluated, and maintained for the classification, protection, and handling of data throughout its lifecycle according to all applicable laws and regulations, standards, and risk level?

Implementation: Documented in the DPA (sync-o.io/dpa) and Privacy Policy (sync-o.io/privacy). Data classified into: (1) ephemeral processing — full ticket/page bodies, in-memory only; (2) persistent metadata — cloudIds, user IDs, configuration; (3) persistent content excerpts — chunk text + embeddings, 90-day TTL; (4) credential storage — AI API keys, encrypted.

Are data security and privacy policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed. DPA bumped to v1.3 on 2026-05-11 reflecting the current data model.

Is a data inventory created and maintained for sensitive and personal information (at a minimum)?

Implementation: Enumerated in DPA §3 and in the Marketplace privacy declaration: User Profile Data (Atlassian User IDs, emails, names from Forge context); Atlassian Context Metadata (cloudId, issue keys, page IDs); Configuration Data (AI provider preferences, notification settings); Content Excerpts & Vector Embeddings (≤1,800 chars per chunk + 768-dim vectors, 90-day TTL).

Is data classified according to type and sensitivity levels?

Implementation: Content excerpts and user profile data classified as highest sensitivity; configuration data as medium; audit metadata (issue keys, page IDs) as low.

Is data flow documentation created to identify what data is processed and where it is stored and transmitted?

Implementation: Data flows documented in the project paper §4: (1) Jira webhook → Forge trigger → AWS SQS → Lambda worker; (2) Lambda fetches ticket/page bodies via Atlassian REST; (3) Lambda calls AI provider (Vertex Belgium / OpenAI US / Anthropic US / Azure OpenAI US) with TLS 1.2+; (4) Generated content posted back to Jira/Confluence via Atlassian REST; (5) Content excerpts + embeddings persisted to DynamoDB eu-west-1 for Smart Picker.

Is data flow documentation reviewed at defined intervals, at least annually, and after any change?

Implementation: Project paper updated on every architectural change (most recently for the OpenSearch → DynamoDB vector migration, May 2026). Annual full review committed.

Is the ownership and stewardship of all relevant personal and sensitive data documented?

Implementation: All Personal Data is the customer's (Controller's) property. Sync-o acts as Processor under GDPR — documented in DPA §2 and §4. Within Sync-o, two individuals have authorized access (owner Philip Amato and one authorized technical contributor); access is logged via AWS CloudTrail.

Is data ownership and stewardship documentation reviewed at least annually?

Implementation: Annual review committed.

Are systems, products, and business practices based on security principles by design and per industry best practices?

Implementation: Forge platform enforces sandbox isolation, scoped permissions, CSP-by-default. Lambda backend follows least-privilege IAM + KMS-encrypted state. Tenants are isolated via DynamoDB partition keys keyed to cloudId — no cross-tenant query path exists in code. OWASP Top 10 baseline followed.

Are systems, products, and business practices based on privacy principles by design and according to industry best practices?

Implementation: Privacy by Default: (a) full ticket/page bodies never persisted, only ≤1,800-char excerpts when needed for Smart Picker; (b) immediate deletion on app uninstall via Forge webhook; (c) BYOM allows customers to keep AI processing under their own provider account; (d) optional features (Smart Picker, BYOM) require explicit customer opt-in.

Are systems' privacy settings configured by default and according to all applicable laws and regulations?

Implementation: GDPR-compliant defaults: data residency in EU (AWS Ireland + Google Belgium for default AI); optional non-EU AI providers require Controller's explicit BYOM configuration, with SCCs in the sub-processor's standard DPA.

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)?

Implementation: All data transfers use TLS 1.2+ (Atlassian REST, AWS service endpoints, AI provider APIs). The default processing path stays within the EEA (Atlassian → AWS Ireland → Google Belgium). Non-EEA transfers (Controller-elected BYOM AI providers in US) are governed by the sub-processor's SCCs.

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)?

Implementation: Data subjects are the Controller's end users (Atlassian site users). Per Forge architecture, all personal data Sync-o holds is keyed to the customer's tenant — uninstallation immediately triggers full deletion of all tenant-specific data via the Forge uninstall webhook handler. Targeted DSR requests can be submitted via [email protected].

Customer Responsibilities: The Controller is the primary point of contact for DSRs from their own end users; the Controller can fulfill access/deletion requests by uninstalling Sync-o or via [email protected].

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)?

Implementation: Sync-o processes data only for the declared purposes: Jira-to-Confluence documentation automation, Smart Picker cross-page semantic search, audit log, and aggregate analytics. No secondary use, no sale, no marketing. Documented in DPA §3.

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)?

Implementation: Sub-processors enumerated in DPA Annex 2: AWS (Ireland), Google Cloud (Belgium), and Controller-elected BYOM AI providers (OpenAI/Anthropic/Microsoft Azure OpenAI in the US). Each operates under its own published DPA + SCCs.

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?

Implementation: Sub-processor list published at sync-o.io/dpa (Annex 2) and sync-o.io/trust before customer installation. The Marketplace listing privacy declaration also enumerates each sub-processor with location and purpose.

Do data retention, archiving, and deletion practices follow business requirements, applicable laws, and regulations?

Implementation: Content excerpts + embeddings: 90-day TTL (DynamoDB native). Audit logs: tenant-configurable retention (default 1 year). Configuration data: persisted while app installed, deleted on uninstall. Customer-supplied AI tokens: deleted on uninstall.

Are processes, procedures, and technical measures defined and implemented to protect sensitive data throughout its lifecycle?

Implementation: At ingestion: TLS 1.2+. In transit between services: TLS 1.2+. At rest: KMS AES-256. In memory during processing: not externally exposed. At deletion: hard-delete on uninstall webhook + 30-day reconciliation sweep.

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?

Implementation: Primary processing: AWS eu-west-1 (Dublin, Ireland). Embeddings + AI generation default: Google Cloud europe-west1 (St. Ghislain, Belgium). Optional BYOM providers: the Controller's selected provider region (US for OpenAI/Anthropic/Azure default).

Are information governance program policies and procedures sponsored by organizational leadership established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: The owner (Philip Amato) is the accountable party for all governance decisions. Policies (DPA, Privacy Policy, Terms of Service, this CAIQ Lite) are published on sync-o.io and version-controlled.

Are the policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed. Last full review: 2026-05-11 (DPA v1.3).

Is there an established formal, documented, and leadership-sponsored enterprise risk management (ERM) program that includes policies and procedures for identification, evaluation, ownership, treatment, and acceptance of cloud security and privacy risks?

Implementation: Risk register maintained as part of the project paper. Risks identified and prioritized: tenant data exposure (highest), regional cloud outage (medium), key compromise (medium), supply-chain compromise via dependencies (medium). Risk treatment documented per item.

Are roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs defined and documented?

Implementation: The owner (Philip Amato) is accountable for all policy decisions, customer contracts, and incident response leadership. The authorized technical contributor implements changes, monitors logs, and remediates issues under the owner's direction.

Are all relevant standards, regulations, legal/contractual, and statutory requirements applicable to your organization identified and documented?

Implementation: Identified: GDPR (Italian + EU jurisdiction), Atlassian Marketplace Cloud App Privacy and Security Requirements, Atlassian Forge platform terms, AWS Customer Agreement, Google Cloud terms. Italian commercial law as the entity's domicile.

Are policies and procedures requiring unattended workspaces to conceal confidential data established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: All authorized personnel work from secured personal Windows workstations with BitLocker full-disk encryption, automatic screen lock after 5 minutes idle, and Windows account passwords. No paper documents containing customer data are produced or printed.

Are policies and procedures requiring unattended workspaces to conceal confidential data reviewed and updated at least annually?

Implementation: Annual review committed.

Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: All authorized personnel work remotely 100% of the time. Remote-work controls: full-disk encryption; MFA on all production-system access (AWS, GitHub, Atlassian); encrypted home Wi-Fi; no production credentials stored unencrypted on local disk.

Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations reviewed and updated at least annually?

Implementation: Annual review committed.

Is a security awareness training program for all employees of the organization established, documented, approved, communicated, applied, evaluated and maintained?

Implementation: Authorized personnel maintain current awareness of OWASP Top 10, GDPR breach handling, social engineering patterns (phishing/vishing), and incident response procedures. Training is informal and self-directed given the small team size; updates triggered by major industry events or new threat patterns.

Are regular security awareness training updates provided?

Implementation: Updates pulled from CSA / OWASP / industry advisories as published. Major-event-driven (new CVEs, new attack techniques) rather than calendar-driven.

Are identity and access management policies and procedures established, documented, approved, communicated, implemented, applied, evaluated, and maintained?

Implementation: IAM policy: least-privilege per AWS IAM principal; MFA enforced on all production-system logins (AWS root, AWS operator IAM, GitHub, Atlassian admin); production AWS access scoped to two identities (owner + one authorized contributor); Forge deploys bound to authenticated Atlassian accounts.

Are identity and access management policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed.

Is system identity information and levels of access managed, stored, and reviewed?

Implementation: AWS IAM principals, GitHub collaborators, and Atlassian admins are tracked in the project paper. Current state: 2 AWS IAM users (root + operator), 2 GitHub repo collaborators (owner + contributor), 2 Atlassian admins (owner + contributor). The personnel roster is static and limited to two authorized individuals, so access changes (provisioning, scope change, or de-provisioning) are reviewed at the moment they occur by the remaining authorized party — an event-driven model commensurate with the operation's small scale — rather than on a calendar-driven cadence.

Is the separation of duties principle employed when implementing information system access?

Implementation: Within the operational scope of a 2-person organization, duties are functionally segregated: the owner approves architectural changes and signs contracts; the contributor implements and operates production systems. Both have AWS and GitHub access (required for failover continuity) but production deploys are reviewed via Git PR before merge.

Is the least privilege principle employed when implementing information system access?

Implementation: Lambda execution roles scoped to specific DynamoDB tables + SQS queues + KMS keys (no wildcard). Operator IAM scoped to specific service actions (no AdministratorAccess). Forge manifest declares only the scopes actually used (read:jira-work, write:jira-work, etc.).

Is a user access provisioning process defined and implemented which authorizes, records, and communicates data and assets access changes?

Implementation: New access (when needed) is provisioned by the owner via AWS IAM Console / GitHub repo settings / Atlassian admin. All grants logged via AWS CloudTrail + GitHub audit log + Atlassian audit log.

Is a process in place to de-provision or modify the access, in a timely manner, of movers / leavers or system identity changes, to effectively adopt and communicate identity and access management policies?

Implementation: On departure of authorized personnel: AWS IAM user deleted; GitHub collaborator removed; Atlassian admin removed; all sessions revoked. Process executable in under 5 minutes given the operational scope.

Are reviews and revalidation of user access for least privilege and separation of duties completed with a frequency commensurate with organizational risk tolerance?

Implementation: Access reviews are event-driven rather than calendar-driven, which is proportionate to a 2-person operation with a static personnel roster. Any change to authorized identities (provisioning, scope change, or de-provisioning) is reviewed at the moment of the change by the remaining authorized party, and recorded in the project paper. The full identity inventory and granted scopes are also documented in the project paper for ongoing reference.

Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated such that administrative data access, encryption, key management capabilities, and logging capabilities are distinct and separate?

Implementation: AWS KMS keys are managed by AWS (no human handles key material). CloudWatch Logs access is granted separately from data-write IAM policies. Admin actions vs runtime actions are split across Lambda execution role (runtime) vs operator IAM (admin).

Is an access process defined and implemented to ensure privileged access roles and rights are granted for a limited period?

Implementation: AWS access via short-lived STS tokens where possible. Root-account access is exception-only and not used for daily operations. Forge deploys require active session re-auth.

Are procedures implemented to prevent the culmination of segregated privileged access?

Implementation: AWS root account is not used for daily operations; an operator IAM with limited scope is used instead. No single non-root principal holds both production-deploy and IAM-grant capability.

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?

Implementation: MFA enforced on: AWS root, AWS operator IAM, GitHub (hardware key required), Atlassian admin. No password-only access paths to production systems exist.

Are digital certificates or alternatives that achieve an equivalent security level for system identities adopted?

Implementation: Lambda execution roles use AWS-issued temporary credentials (no static keys). Forge platform uses signed JWT tokens for inter-service auth. Atlassian REST calls use OAuth 2.0 bearer tokens issued by the Forge platform.

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for communications between application services (e.g., APIs)?

Implementation: All inter-service communication uses HTTPS/TLS 1.2+. Forge resolvers are invoked via Atlassian's signed-context bridge (not exposed as public REST). AWS Lambda invoked from Forge via signed request through Atlassian's invokeRemote with a custom authorizer.

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information processing interoperability?

Implementation: Data exchanged with Atlassian via standard Atlassian REST APIs and ADF (Atlassian Document Format). Content sent to AI providers in standard JSON. No proprietary formats.

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for application development portability?

Implementation: Sync-o is built on standard frameworks (Atlassian Forge, Python on AWS Lambda) using widely available open-source libraries. No vendor lock-in beyond the Atlassian platform itself.

Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information/data exchange, usage, portability, integrity, and persistence?

Implementation: All canonical customer data lives in the customer's Confluence and Jira instances (the source of truth). Sync-o-side persistence is metadata + ephemeral excerpts only. Customers can export full content from Atlassian at any time via Atlassian's native tools.

Customer Responsibilities: Customers may export their Confluence/Jira data through standard Atlassian export tools at any time.

Are interoperability and portability policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed.

Are communications between environments monitored?

Implementation: CloudWatch Logs capture all Lambda invocations, errors, and inter-service calls. AWS GuardDuty (where enabled) flags anomalous network behavior. Atlassian Forge logs platform-level invocation traces.

Are communications between environments encrypted?

Implementation: All inter-service traffic uses TLS 1.2+. AWS service-to-service traffic within eu-west-1 uses AWS's encrypted backbone. Atlassian Forge → AWS Lambda traffic flows through Atlassian's signed-tunnel mechanism with TLS terminated at AWS API Gateway.

Are communications between environments restricted to only authenticated and authorized connections, as justified by the business?

Implementation: Lambda invocation requires either an AWS-signed request (from authorized Lambda) or a signed Forge bridge token via custom authorizer. No anonymous endpoints exposed.

Are network configurations reviewed at least annually?

Implementation: Annual review committed.

Are network configurations supported by the documented justification of all allowed services, protocols, ports, and compensating controls?

Implementation: All AWS resources use default service endpoints (HTTPS on 443); no custom VPC ingress; no SSH; no public IPs on Lambdas. Network allowlist documented in template.yaml.

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?

Implementation: AWS Lambda runs on Amazon Linux 2 with automatic AWS-managed patching. No OS / hypervisor under Sync-o's direct management. AWS shared-responsibility model applies — OS layer is AWS's responsibility.

Are applications and infrastructures designed, developed, deployed, and configured such that CSP and CSC (tenant) user access and intra-tenant access is appropriately segmented, segregated, monitored, and restricted from other tenants?

Implementation: Multi-tenant data is logically isolated via DynamoDB partition keys keyed to cloudId. No cross-tenant query path exists in application code; the partition key is enforced at every read. The Lambda execution role's IAM policy further prevents cross-tenant enumeration.

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?

Implementation: All migrations (e.g., the May 2026 OpenSearch → DynamoDB vector migration) use TLS-protected AWS API calls. Data never leaves eu-west-1 during internal migrations.

Are processes, procedures, and defense-in-depth techniques defined, implemented, and evaluated for protection, detection, and timely response to network-based attacks?

Implementation: Defense-in-depth layers: (1) AWS Shield Standard for DDoS protection (automatic); (2) API Gateway throttling; (3) Lambda concurrency limits; (4) Forge platform rate-limiting; (5) Application-level authentication via custom authorizer.

Are logging and monitoring policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: All Lambda invocations logged to CloudWatch with standard retention (14 days default, extended for audit-relevant events). Application audit log persisted to DynamoDB. Atlassian Forge logs captured automatically by the platform.

Are policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed.

Is access to audit logs restricted to authorized personnel, and are records maintained to provide unique access accountability?

Implementation: CloudWatch Logs access scoped to owner + operator IAM. CloudTrail logs every API call to those logs themselves. Application audit log in DynamoDB is read-only from the operator IAM; writes only via Lambda execution role.

Are security audit logs monitored to detect activity outside of typical or expected patterns?

Implementation: CloudWatch Alarms configured on Lambda error rates and throttling. Forge platform sends email alerts on app errors. AWS GuardDuty (where enabled) flags anomalies.

Is a process established and followed to review and take appropriate and timely actions on detected anomalies?

Implementation: Alerts route to [email protected]. Triage performed within 24h for low-severity, immediately for high-severity (incident).

Is a security incident response plan that includes relevant internal departments, impacted CSCs, and other business-critical relationships (such as supply-chain) established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: Incident response plan: (1) detect via CloudWatch alarms / customer report / GuardDuty; (2) triage severity and scope; (3) contain (revoke credentials, isolate affected Lambda); (4) eradicate (patch + redeploy); (5) recover (PITR restore if needed); (6) post-mortem documented in project paper; (7) GDPR breach notification to affected Controllers + Italian DPA within 72h if breach involves personal data.

Customer Responsibilities: Customers should report any suspected incidents to [email protected].

Is the security incident response plan tested and updated for effectiveness, as necessary, at planned intervals or upon significant organizational or environmental changes?

Implementation: Real-world incidents have exercised the plan (May 2026: a cross-product cleanup-agent inadvertently deleted DynamoDB tables → recovered via PITR within 1 hour; post-mortem in project paper). Annual tabletop committed.

Are processes, procedures, and technical measures for security breach notifications defined and implemented?

Implementation: Breach notification process: (a) confirm scope; (b) email affected Controllers within 72h of confirmed breach involving personal data; (c) notify Italian DPA (Garante per la protezione dei dati personali) per GDPR Art. 33 within 72h; (d) publish a transparent post-mortem.

Are security breaches and assumed security breaches reported (including any relevant supply chain breaches) as per applicable SLAs, laws, and regulations?

Implementation: GDPR 72-hour notification rule observed. No breaches to date.

Is the SSRM applied, documented, implemented, and managed throughout the supply chain for the cloud service offering?

Implementation: SSRM documented in DPA Annex 2 (sub-processors) and in this CAIQ Lite. Each sub-processor (AWS, Google, OpenAI, Anthropic, Microsoft) has their own published DPA + SCCs that Sync-o relies on.

Is the shared ownership and applicability of all CSA CCM controls delineated according to the SSRM for the cloud service offering?

Implementation: This CAIQ Lite delineates ownership per control (CSP-owned / CSC-owned / 3rd-party outsourced / Shared) in the SSRM column.

Is an inventory of all supply chain relationships developed and maintained?

Implementation: Customer-data sub-processors are enumerated in DPA Annex 2: AWS (Ireland), Google Cloud (Belgium), OpenAI (US, optional BYOM), Anthropic (US, optional BYOM), Microsoft Azure OpenAI (US/elected region, optional BYOM). Atlassian Forge is the underlying platform on which Sync-o is deployed; customers contract with Atlassian directly so it is not listed as a Sync-o sub-processor. Operational tools that do not process customer Atlassian content (GitHub for source control, Cloudflare Pages for marketing-site hosting) are excluded from the sub-processor inventory.

Are policies and procedures to protect against malware on managed assets established, documented, approved, communicated, applied, evaluated, and maintained?

Implementation: AWS Lambda runs on AWS-managed Amazon Linux 2 — OS-level anti-malware is AWS's responsibility. Authorized personnel's Windows workstations run Microsoft Defender Antivirus with automatic signature updates. No file uploads accepted from customer-facing surfaces; Sync-o processes only Atlassian text content.

Are asset management and malware protection policies and procedures reviewed and updated at least annually?

Implementation: Annual review committed.

Are processes, procedures, and technical measures defined, implemented, and evaluated to enable scheduled and emergency responses to vulnerability identifications (based on the identified risk)?

Implementation: Critical CVEs (CVSS 9+): targeted for same-day patch + deploy. High (7-8.9): within 14 days. Medium/Low: within 30-90 days. Dependabot generates remediation PRs automatically.

Are processes, procedures, and technical measures defined, implemented, and evaluated to update detection tools, threat signatures, and compromise indicators weekly (or more frequent) basis?

Implementation: GitHub Dependabot continuously pulls fresh CVE data from the GitHub Advisory Database. CodeQL queries are updated by GitHub on each Actions run. AWS-side OS-level malware definitions managed by AWS.

Are processes, procedures, and technical measures defined, implemented, and evaluated for vulnerability detection on organizationally managed assets at least monthly?

Implementation: Dependabot scans on every push (continuous). CodeQL SAST scans on every PR. pip-audit + npm audit run in CI on each build.

Is a process defined and implemented to track and report vulnerability identification and remediation activities that include stakeholder notification?

Implementation: Open vulnerabilities tracked in the GitHub Security tab (Dependabot + CodeQL findings). Remediation recorded in commit history. Material findings affecting customer data are disclosed in the changelog at sync-o.io/changelog.

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?

Implementation: Authorized personnel use approved tools only: Git, AWS CLI, Forge CLI, Node.js (for Forge), Python (for AWS Lambda), VS Code, Atlassian admin console. No production credentials exposed to unapproved apps.

Is an inventory of all endpoints used and maintained to store and access company data?

Implementation: 2 endpoints inventoried (owner's workstation + authorized contributor's workstation). Both managed with full-disk encryption + auto-lock + standard OS auto-update.

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?

Implementation: Endpoint controls on all authorized Windows workstations: BitLocker full-disk encryption; Windows Update automatic patching; automatic screen lock; MFA on all production-system logins from endpoint; no production credentials stored unencrypted on disk.

Are all relevant interactive-use endpoints configured to require an automatic lock screen?

Implementation: Both authorized endpoints configured for automatic screen lock after 5 minutes of inactivity.

Are anti-malware detection and prevention technology services configured on managed endpoints?

Implementation: Microsoft Defender Antivirus is enabled on all authorized Windows workstations with automatic, cloud-delivered signature updates.

Are software firewalls configured on managed endpoints?

Implementation: Windows Defender Firewall is enabled by default on all authorized endpoints. Inbound connections are blocked unless explicitly required.

Are processes, procedures, and technical measures defined, implemented, and evaluated to enable remote company data deletion on managed endpoint devices?

Implementation: Authorized Windows endpoints support remote-wipe via BitLocker recovery-key revocation plus Microsoft "Find My Device" remote-wipe (Microsoft-account-linked). Production credentials are not stored on disk; loss of an endpoint does not expose production systems, which require MFA via a secondary hardware factor.