Security Questionnaire

In progress - under review

This page collects the answers prepared for customer SaaS security questionnaires (application security, NIST CSF controls, general vendor assessment and evidence requests). The content is draft: it is still being reviewed for accuracy and completeness, and several answers document known gaps or are pending input from the Platform team. Do not send any answer to a customer before it has been reviewed and approved.

Answers are derived from the published governance policies and engineering documentation. Where an answer states a gap, that gap is intentional and documented - keep it that way rather than softening it.

Application Security

Question	Answer
AS1: Do you have a Secure Development Life Cycle in place?	Yes. Appcircle has a formal SDLC Policy (owned by Engineering Management as Security Program Owner, effective 2026-02-05). Lifecycle phases: need identification -> requirements (with a security assessment) -> system design (functional + security + scalability) -> build & test (covers security vulnerabilities) -> evaluation (independent testing where possible) -> deployment (per Change Management Policy). Security controls woven throughout: • Separation of duties (dev/test/prod logically separated; prod access explicit, not default) • Peer code review by someone other than the author, versed in secure coding • Secure coding standards + annual security training (OWASP Top 10 awareness) • OWASP Top 10 / SANS compliance for anything on the infra • Human approval required for all production changes; no unapproved automated updates • Test/default credentials removed before release; secure error handling (no internal detail leakage) It also aligns with SOC 2, ISO/IEC 27001:2022 (A.8.25-A.8.31), GDPR Art. 25, and KVKK Art. 12. Detailed internal procedures are kept separately and shared under agreement. Source: sdlc-policy
AS2: Do you have a defined and documented application security standard?	Yes, across a few layers: • SDLC Policy - mandates OWASP Top 10 / SANS coverage, peer code review by someone knowledgeable in secure coding, annual security training, removal of test/default credentials, and secure error handling. Aligned with SOC 2, ISO 27001:2022 (A.8.25-A.8.31), GDPR Art. 25, KVKK Art. 12. (sdlc-policy) • Information Security Policy - sets the overall program and lists secure development/change management as a control domain. (information-security-policy) • Engineering best-practices standard - a concrete, code-level app-security standard: SSRF prevention (allowlisting, scheme/redirect/path validation), secret handling, input validation, debug-code isolation, cryptography/CSPRNG, TLS/cert validation, with code examples. (best-practices) • SAST program - active static-analysis scanning with individual scan reports and follow-ups. (sast-index)
AS3: Do you have defined and documented Secure Coding standard/guidelines?	Yes, at two levels: • Policy mandate - the SDLC Policy requires developers to follow secure coding standards, mandates annual security training with OWASP Top 10 awareness, requires all software to prevent OWASP Top 10 / SANS issues, and requires peer review by reviewers knowledgeable in secure coding, secure error handling, and removal of test credentials before release. The Information Security Policy lists "Secure development and change management" as a control domain. • Concrete technical guidelines - an internal secure-coding best-practices doc with enforceable rules: SSRF prevention (host allowlisting, no user-controlled request targets, disabled redirects, centralized validation), secret handling, API input validation (FluentValidation), debug-code restrictions (#if DEBUG, no debug endpoints in prod), CSPRNG for security-sensitive randomness, and TLS/cert validation rules, with code examples. A SAST scan index operationalizes the testing side.
AS4: Do developers follow the Secure Coding standards?	Yes, enforcement in practice: • Peer code review is required and structurally owned - every repo has a CODEOWNERS file naming who's accountable for review; the SDLC and Change Management policies require review by someone other than the author, knowledgeable in secure coding. • SAST with tracked triage - a dated scan report (2025-11-14) lists findings per service, each classified (Valid / False Positive / Risk Accepted / Fix Required) and cross-referenced back to the secure-coding standard's numbered rules (e.g. [Secret Handling 4], [Cryptography & Randomness 1]). So findings are triaged against the written standard, not just generated. • Vulnerability Management Policy ties it together: secure-dev training, peer review, third-party scanning, and annual pen testing, with remediation SLAs (Urgent 1d / Critical 3d / High 30d / Medium 90d). SAST/Quality gates are not yet a blocking, automated CI check. Current evidence is a point-in-time scan plus manual review, not a continuous gate. However, there is a plan on integration SonarQube and OWASP inside the existing Jenkins pipelines.
AS5: Do you conduct secure code review of the code developed before deployment or release?	Yes. Secure code review is mandatory before any code is deployed or released: Peer code review is required on every change - the SDLC and Vulnerability Management policies both require all code changes to be reviewed by at least one person other than the author, with reviewers knowledgeable in secure coding, and the review explicitly assesses both code quality and potential security vulnerabilities. It's gated, not optional - changes are managed in GitHub with enforced peer review/approval; the Jenkins CI/CD pipeline runs automated checks and promotes through dev -> test (impact assessment, integration testing, review, approval) -> production. A change reaches production only after passing all required automated and manual checks. Additional pre-release security coverage - the build-and-test phase covers security vulnerabilities, and an independent evaluation phase verifies security before deployment. Detailed review workflows are maintained separately, but the requirement (security-aware peer review before release) is explicitly documented. Sources: sdlc-policy change-management-policy vulnerability-management-policy
AS6: Do you conduct manual or automated penetration test before any change is introduced to the application ?	Not per change. Penetration testing is conducted at least annually by a qualified third party, and is both manual and automated (automated scanning combined with human-led exploitation to catch what tools miss). It is not run on every individual change or release. Per-change security assurance instead comes from other SDLC controls: Mandatory security-aware peer code review on every change Secure coding standards + OWASP Top 10 compliance A build-and-test phase with security-vulnerability coverage, plus an independent evaluation phase before deployment Continuous/automated vulnerability scanning of systems, dependencies, and infrastructure (separate from the annual pentest) Exact tooling/vendor and pentest scope are maintained separately and shared only under agreement. Sources: vulnerability-management-policy sdlc-policy
AS7: Do you have secure code repository and version control practices in place?	Yes. Practices are documented across governance policies and engineering docs: Access control - GitHub org ownership restricted to managers as org owners (Osman Kibar, Enver Gökmen, Özcan Övünç); least-privilege roles (Read/Write/Maintain); no shared accounts; MFA and SSO via Microsoft Entra ID; quarterly access reviews; access revoked within one business day of offboarding. Branch protection - configured by org owners alongside team membership and repo roles (specific rule configs are internal engineering config, not published). Peer review enforcement - SDLC Policy requires review by someone other than the author; every repo carries a CODEOWNERS file naming who's accountable for review, updated when responsibility changes. Secret management - Vaultwarden (self-hosted, AES-256-GCM/Argon2id, Entra SSO, RBAC) for team credentials; application secrets migrating from HashiCorp Vault to OpenBao with least-privilege service-to-secret scoping, TLS, and audit logging; test/default credentials removed before release; no prod secrets in dev/test. Audit / version history - Git commit/PR history is the code-change audit trail; the Logging & Monitoring Policy requires logging of admin actions, privilege changes, and secret/key access, with logs centralized, encrypted in transit, tamper-protected, and non-erasable by their own actor. Detailed workflows/configs are maintained separately and shared under agreement.
AS8: Do you perform periodic vulnerability scan of the application?	Yes, under a formal Vulnerability Management Policy (effective 2026-02-05, owned by Engineering Management). • What's scanned - all Appcircle-operated systems, services, and infrastructure (including production on GCP), plus third-party components/dependencies. • Methods - third-party vulnerability scanning of systems/dependencies/infra; SAST scans logged per service (e.g. a 2025-11-14 run over AppParser, AspNetCore, Appcircle Core, License Server, Apigateway, Build Server, each finding classified Valid / False Positive / Risk Accepted / Fix Required); annual third-party penetration testing; plus peer review and secure-dev training. • Cadence - pentest at least annually; the SAST index tracks dated recurring scans. Exact scanning-tool schedules are maintained separately as internal procedure. • Remediation SLAs - Urgent 1 day, Critical 3 days, High 30 days, Medium 90 days, Low best-effort. All findings are logged and tracked to resolution; exceptions must be documented and approved. Aligned with SOC 2, ISO 27001:2022 (A.8.8), GDPR Art. 32, KVKK Art. 12. Sources: vulnerability-management-policy sast-index
AS9: Do you allow Critical or High risk vulnerabilities identified in the application to be released in production?	Critical/High vulnerabilities are not simply allowed to ship, but the documented control is a remediation SLA plus mandatory human approval, rather than an explicit automated release-blocking gate. Exceptions / risk acceptance - must be documented (justification, scope, duration, compensating controls), approved by the policy owner (Engineering Management / Security Program Owner) or delegate, and reviewed before expiry. Formal risk acceptance sits under the Risk Assessment Policy, signed off by Engineering Management, with a stated low tolerance for risks involving unauthorized access to or disclosure of customer data. Sources: vulnerability-management-policy sdlc-policy risk-assessment-policy

NIST CSF - Identify

Question	Answer
ID.AM-2: Are cybersecurity roles and responsibilities clearly defined for employees as well as third-party stakeholders (e.g., suppliers, customers, partners)?	Yes for employees and vendors; more limited/implicit for customers and partners. • Employees (by role, in every governance policy's "Roles and responsibilities" section): Engineering Management (Policy Owner / Security Program Owner) - accountable for each policy, approves exceptions and risk acceptance (the de facto CISO role; no separate named CISO). Engineering / Platform / Operations - operational execution of controls (access, scanning/remediation, logging, network, DR, incident response, vendor onboarding). Developers - SDLC/change-management duties, code remediation, required logging. All personnel - read/acknowledge/comply and report incidents. Plus a company-wide RACI matrix requiring one Accountable owner per task and @team/security at least Consulted whenever security/data/compliance is affected. • Vendors/suppliers/partners - explicitly defined in the Vendor Management Policy: every vendor has a named Appcircle accountable owner in a vendor register; formal security assessment and management approval before onboarding; contracts must cover data protection, breach notification, sub-processor limits, and data return/deletion. "Partners" are covered under this same vendor scope, not a separate role. • Customers - narrower and mostly implicit. The main explicit statement is in the System Access Control Policy: self-hosted customer deployments operate under the customer's own access-control responsibility. A separate customer-facing shared responsibility model is not currently published as a standalone document. Sources: information-security-policy vendor-management-policy system-access-control-policy responsibility-matrix
ID.GV-1: Is there a cybersecurity or information security policy in your company?	Yes. Appcircle has a formal Information Security Policy (effective 2026-02-05, owned by Engineering Management as Security Program Owner), reviewed at least annually or on significant business/technology/regulatory change. Scope - the workforce and anyone with access; all corporate IT, cloud infra, and product services; third parties processing Appcircle/customer data on its behalf. Principles - risk-based security, least privilege / need-to-know, defense in depth, secure by design, environment segregation, monitoring & accountability, data protection by default. Built around confidentiality, integrity, availability. Control domains - access control, asset management, data protection & privacy, cryptography & key management, secure development & change management, logging & monitoring, vulnerability management, incident response, business continuity/backup/DR, vendor & third-party security, physical security. Roles - Engineering Management owns it; Engineering/Platform/Operations implement and operate controls; all personnel comply and report incidents. It's the umbrella document, supported by ~20 topic-specific policies (SDLC, Access Control, Vulnerability Management, Incident Response, Vendor Management, Logging & Monitoring, and more). Exceptions must be documented and approved by the policy owner. Source: information-security-policy
ID.GV-2: Do you abide by all applicable legal and regulatory requirements regarding cybersecurity, including privacy obligations?	Yes. Appcircle's governance program is explicitly built around and mapped to recognized frameworks and privacy regulations, with a "Regulatory alignment" section in every policy. Frameworks / regulations aligned to: SOC 2 (Trust Services Criteria) - cited across nearly every policy ISO/IEC 27001:2022 - specific Annex A clauses per policy GDPR (EU 2016/679) - Articles 32, 25, 5, 28, 33/34, 35 KVKK (Turkey, Law 6698) - Article 12, alongside GDPR ISO/IEC 27701:2019 (privacy management) and NIST SP 800-88 (media sanitization) in the disposal policy Privacy / data-protection obligations: Information Security Policy establishes a data-protection & privacy control domain (classification, handling, retention, secure deletion). Data Retention & Disposal Policy supports GDPR/KVKK storage-limitation and erasure, and defines supported data-subject rights (erasure, restriction, portability) via a Data Protection Contact role. Incident Response Plan codifies breach notification: GDPR Art. 33 (72h to authority), Art. 34 (affected individuals), KVKK Art. 12 equivalent. Logging policy forbids plaintext credentials/PII in logs beyond necessity. One honest nuance: the docs describe Appcircle's policies as designed to support/align with these frameworks. They don't assert that Appcircle itself currently holds a SOC 2 attestation or ISO 27001 certification. The only cited third-party SOC 2 Type II evidence is for GCP (its infrastructure provider), whose physical/network controls Appcircle relies on and reviews under vendor management. Sources: information-security-policy data-retention-and-disposal-policy incident-response-plan risk-assessment-policy
ID.RA-2: Do you identify and document cyber threats, both internal and external?	Yes, through a formal risk-assessment process, with internal and external threats captured across complementary policies. Risk Assessment Policy (ISO 27001-consistent, SOC 2-aligned) - a five-step process: Asset identification (systems, data, processes, third-party dependencies) Threat and vulnerability identification per asset (e.g. unauthorized access, data loss, service disruption), based on exposure and operational context Risk evaluation (likelihood × impact -> Critical/High/Medium/Low) Risk treatment (Mitigate/Accept/Transfer/Avoid) Risk register recording each risk, severity, treatment, owner, and review status Full assessment runs at least annually, plus ad hoc on new systems, major architecture changes, new regulations, or post-incident. Engineering Management signs off the register; all personnel report newly identified risks. Internal vs external threats - captured operationally rather than in one split document: Vulnerability Management Policy explicitly aims to "reduce the risk of exploitation by internal or external actors" - internal-facing controls (secure-dev training, peer review) plus external-facing ones (third-party scanning, annual pentest). External threat intake via a Responsible Disclosure process; internal intake via mandatory incident/weakness reporting. Aligned to ISO 27001:2022 A.5.7 (Threat intelligence) for external threat-landscape awareness. The risk register itself and the detailed scoring methodology are maintained separately, not in the published docs. Sources: risk-assessment-policy vulnerability-management-policy information-security-policy
ID.RA-4: Do you prioritize actions to mitigate risks?	Yes. Prioritization by likelihood and impact (Risk Assessment Policy): risks are evaluated on "Likelihood: the probability of the threat being realised" and "Impact: the potential harm...", then "assigned a severity level (e.g., Critical, High, Medium, Low) to support prioritisation." The Information Security Policy states the principle directly: "Security controls are selected and prioritized based on risk." Risk treatment options (Risk Assessment Policy) - for each risk one of: Mitigate (reduce likelihood/impact), Accept, Transfer, or Avoid; decisions and residual risks recorded in a risk register. Remediation SLAs by severity (Vulnerability Management Policy): "Vulnerabilities are prioritised and remediated according to their severity rating" - Urgent 1 day, Critical 3 days, High 30 days, Medium 90 days, Low best-effort. Risk appetite - low tolerance for unauthorized customer-data access, material production disruption, and regulatory non-compliance; higher residual risk accepted only for lower-severity findings with documented, approved compensating controls. Honest caveat, per the docs themselves: the actual risk register contents, the detailed numeric scoring methodology, and remediation workflows are explicitly "maintained separately" and are not in the published documentation. So the prioritization framework is documented; the concrete register and scoring rubric are not visible in these docs. Sources: risk-assessment-policy vulnerability-management-policy information-security-policy

NIST CSF - Protect

Question	Answer
PR.AC-1: Do you have identity and access management processes for users and devices covering the whole lifecycle (issuance, management, verification, revocation, audit)?	Yes, documented across the full lifecycle for both users and devices. Issuance / provisioning - access requires formal approval before provisioning, documented via onboarding checklist capturing the access and approver; individually named accounts, least privilege, default passwords changed on first use. Company devices are pre-configured with required security controls before issuance. Management - GitHub via named org owners (Read/Write/Maintain) with CODEOWNERS; GCP via Entra ID group sync; credentials only in self-hosted Vaultwarden (team collections, privileged collections for leads); privileged access minimized and documented separately. Devices: full-disk encryption, anti-malware, patch management, screen lock, no local sensitive-data storage (incl. BYOD). Verification / authentication - MFA enforced via Microsoft Entra ID Conditional Access; SSO via Entra ID wherever supported. Revocation / deprovisioning - access revoked within one business day of separation; a prioritized offboarding checklist (SSO/IdP first) covering M365, Slack, GitHub, Jenkins, GCP, infra IAM/SSH, K8s RBAC, secret stores, etc., with an OFF-#### evidence record. Lost/compromised devices trigger remote wipe + revocation. Audit / access reviews - access reviewed at least quarterly (checking accounts that should be revoked, excessive permissions, orphaned/inactive accounts), with heightened scrutiny for privileged access; device compliance via periodic review. Mapped to SOC 2, ISO 27001:2022 (A.8.1; A.5.15-A.5.18, A.8.2-A.8.5), GDPR Art. 32, KVKK Art. 12. Honest caveats: the granular procedures (exact review cadence mechanics, sign-off, evidence format) are explicitly maintained separately, not in the public policy text. And note the above is Appcircle's internal workforce/device IAM; the product also offers customer-facing identity features (SSO, RBAC, auth activity log) but I found no product-level SCIM/automated-deprovisioning or periodic access-review feature documented. Sources: system-access-control-policy endpoint-device-security-policy onboarding offboarding
PR.AC-2: Do you manage and protect physical access to IT assets?	Yes, physical access is managed and documented, split across three areas, with a couple of honest gaps worth flagging. Data center / production infrastructure - fully delegated to Google Cloud. Per the Physical Security Policy, physical/environmental controls for GCP data centers are operated by Google, "evidenced by GCP's SOC 2 Type II report," which Appcircle reviews under its vendor management program. The policy states no sensitive production data is stored on-premises. Office - the Istanbul office (used on a limited/flexible basis, predominantly remote workforce) has documented controls: access restricted to authorized personnel, visitor acknowledgement/escort at reception, clean desk, locked storage for sensitive documents, and no unattended devices. Device / asset - screen lock + auto-lock, full-disk encryption (FileVault/BitLocker), no device sharing, immediate loss/theft reporting enabling remote wipe, and secure wipe/shredding/certified destruction at end of life. Owned by Engineering Management; mapped to SOC 2, ISO 27001:2022 (A.7), GDPR Art. 32, KVKK Art. 12; reviewed at least annually. Honest caveats (documented divergences): The Physical Security Policy frames production as "entirely on GCP," but other internal docs describe self-operated physical infrastructure it doesn't reconcile: macOS build runners in a Teknotel datacenter, an on-prem lab (5-6 hosts, ADR-0004), and OVH-hosted infra. There's no physical-access-control policy (badges, CCTV, visitor logs) for the Teknotel facility or on-prem lab - only operational setup/ticketing guides. The datacenter Mac mini build hosts run with FileVault intentionally disabled (a documented, approved scoped exception to the endpoint policy, not a silent gap). Detailed office access mechanics (badge system, visitor-log retention) are deferred to a separate internal doc not present in these repos. Sources: physical-security-policy endpoint-device-security-policy data-retention-and-disposal-policy 0004-virtualization-platform
PR.AC-5: Are network security and integrity protected (e.g. network segregation, network segmentation)?	Yes, network security and integrity are protected and documented at both policy and infrastructure level. Coverage is strong on encryption-in-transit, segmentation, and firewalling; thinner on a named intrusion-detection product. Encryption in transit - Network Security Policy: all data between services and between services and users is TLS-encrypted (minimum TLS 1.2), AES-256 for GCP/platform, unencrypted protocols not permitted for sensitive data. Self-hosted product supports configurable TLS versions (recommends TLS 1.2/1.3). Engineering best-practices forbid disabling cert validation. Network segmentation / firewalls - documented at policy level (GCP VPC isolation between environments, default-deny firewall rules permitting only explicit flows, prod/dev/test separation) and concretely at infrastructure level: Proxmox SDN zones (ingress/isolated/k8group/mgmt) with cluster default-deny (policy_in=DROP, policy_forward=DROP) Teknotel edge NGFW (FortiGate 3200F) - allow-list + default-deny, zone segmentation (LAN/WAN/VPN), stateful L3/L4 rules, VPN termination VM/LXC hardening - SSH key-only, no root login, only required ports open WAF / DDoS - a WAF handles global IP throttling in cloud deployments (confirmed operational via incident IR-2026-0407); Cloudflare provides DDoS mitigation for public-facing services. Honest gap - intrusion detection: no dedicated IDS/IPS product is documented as deployed. It appears only as (a) a required control category in the Logging & Monitoring Policy and (b) an available FortiGate feature not confirmed as enabled. Broader monitoring/alerting for anomalies and unauthorized access is documented. Detailed firewall rulesets and IDS specifics are explicitly kept in separate internal standards not published here. Sources: network-security-policy logging-and-monitoring-policy network-firewall firewall
PR.AC-6: Do you adapt the level of authentication for users, devices, and other assets (e.g., single-factor, multi-factor) depending on the level of risk of the transaction?	Honestly: no, not in the documented sense. There is no documented risk-based, adaptive, or step-up authentication at Appcircle. MFA is a blanket requirement, not tiered by transaction risk. What is documented: MFA required for all system logins, directly or via Microsoft Entra ID SSO which enforces it (Acceptable Use Policy, Endpoint Device Security Policy). The System Access Control Policy says MFA is "enforced for all applicable systems via Microsoft Entra ID Conditional Access policies" - but Conditional Access is described purely as the enforcement mechanism for blanket MFA, with no mention of sign-in risk, user risk, or device-compliance-based conditions. Privileged access is minimized and gets heightened scrutiny during periodic reviews - but that's access-review oversight, not a stronger authentication mechanism at login/transaction time. The "risk-based approach" in the Information Security / Risk Assessment policies refers to prioritizing security controls, not adapting authentication strength per transaction. Notably contrary to step-up: the product docs state the CLI does not enforce 2FA even when it's enabled on the account - a documented gap, the opposite of adaptive enforcement. Explicitly not found in either doc set: risk-based/adaptive/step-up authentication, or Entra Conditional Access risk policies (sign-in/user-risk/device-compliance conditions). The policy does note detailed privileged-access standards are "maintained separately," so more granular internal detail may exist, but nothing in the docs describes authentication as risk-tiered. Sources: system-access-control-policy acceptable-use-policy authentications
PR.DS-3: Have you implemented protections against data leaks?	Yes, a layered set of data-leak protections is documented, with one honest scope limitation on dedicated DLP tooling. Encryption in transit - TLS 1.2 minimum between all services and users, AES-256; unencrypted protocols not permitted for sensitive data. Self-hosted must install with HTTPS. Encryption at rest - GCP-managed AES-256 on all production data stores by default; databases with non-public data require encryption at rest; full-disk encryption on all endpoints (FileVault/BitLocker/LUKS2). Secrets management - engineering rules mandate secrets are never passed as CLI args, never written to logs/exceptions in plaintext, cleared from memory; infra uses OpenBao (secrets delivered at runtime, never committed to source, chmod 0600). Log redaction - logs must not contain plaintext passwords, credentials, unmasked card data, or PII beyond what's needed; sensitive command strings sanitized/masked before logging. Data classification - four tiers (Restricted/Confidential/Internal/Public) with handling rules tied to retention and disposal. No local storage on endpoints - sensitive/customer data must not be stored on local drives (incl. BYOD); approved cloud storage only. Secure disposal - classification/medium-specific (cryptographic erasure per NIST SP 800-88, secure overwrite, cross-cut shredding, secure wipe before reassignment). Access controls - least privilege, MFA/SSO, quarterly access reviews, revocation within one business day; admins can't erase their own activity logs. Honest gap - dedicated DLP tooling: the only named DLP tool is Microsoft Purview, and it is explicitly scoped to the corporate environment (email/collaboration) - not the Appcircle product/platform. No document describes platform-level DLP scanning of customer source code, build artifacts, or binaries flowing through CI/CD. If such platform DLP exists, it is not documented. Also, a referenced standalone "Encryption Policy" doesn't exist as its own file (encryption is documented piecemeal), and OpenBao currently runs over plain HTTP internally (TLS is a pending task) - a documented exception. Sources: network-security-policy logging-and-monitoring-policy asset-management-and-data-classification-policy data-retention-and-disposal-policy best-practices
PR.DS-4: Do you use integrity checking mechanisms to verify software, firmware, and information integrity?	Partially. Several integrity mechanisms are documented, but coverage is uneven and firmware integrity specifically is not documented at all. Product (customer-facing) integrity features: Code/artifact signing - core product capability: Signing Identities (iOS certs/profiles, Android keystores), Re-sign Binary, and real code signing + Apple notarization on macOS runners (codesign --timestamp, notarytool submit). Checksums/hashes - webhook payloads signed with HMAC-SHA256 (ac_signature header); runner VM images verified via MD5 checksum + SSH host-key SHA256 fingerprint; optional checksum verification advised for binary downloads. TLS integrity - CLI<->server communication uses verified TLS; docs warn against disabling cert validation. Internal integrity controls: Log integrity - the closest thing to file-integrity monitoring: "Integrity monitoring or change-detection mechanisms are applied to detect unauthorized alterations to log data" (scoped to logs only). Backup/DR integrity - post-restore verification tests by QA, semi-annual restore drills, and checksum-based transfer verification (rclone copy --checksum, "verify data integrity after transfer"). Transport/at-rest - TLS 1.2 min, GCP-managed AES-256. Container supply chain - SBOM/provenance is a stated driver in ADR-0011's image-hardening initiative, but shown as an unchecked/in-progress item, not an enforced control. Explicitly NOT documented (searched, no matches): Firmware integrity - not mentioned anywhere in the corpus. Dependency/package integrity - no lockfile checksum verification or install-time SBOM verification as a security control (only CVE vulnerability scanning). Commit signing - no GPG-signed/verified commit requirement. General host file-integrity monitoring (FIM) - none beyond the log clause; no Tripwire/AIDE-type tooling. Container image signing/verification (cosign/sigstore) at deploy time - not documented, only the SBOM consideration above. Sources: signing-identities webhooks logging-and-monitoring-policy disaster-recovery-plan 0011-keycloak-image-base-selection
PR.IP-4: Do you perform, maintain, and test data backups?	Yes, for Appcircle-managed environments backups are performed, maintained, and restore-tested under a formal Disaster Recovery Plan. Self-hosted deployments are explicitly the customer's responsibility. Scope & frequency (production, Appcircle-managed): PostgreSQL - daily automated Cloud SQL backups + on-demand before migrations MongoDB - daily GCP Backup & DR vault backups Object storage - continuous multi-region replication Container images - Artifact Registry on every deployment Vault secrets - continuous, GCS backend with KMS auto-seal (Non-production has no automated daily backups.) Offsite / redundancy - multi-region storage + cross-region replication, production only; DR strategy is failover to a secondary GCP project in a different region. Restore testing IS documented and scheduled: Quarterly tabletop exercises Semi-annual component restore drills (restore to an isolated target project) Annual full-stack DR simulation RTO / RPO - RTO < 16 hours (full platform), RPO < 24 hours (based on daily backups). Retention - governed by a separate internal retention schedule (specific periods not published); backups disposed at the next rotation aligned to source-data retention. Honest caveats: Backup encryption is not explicitly documented - only generic "encryption where appropriate" language; the KMS reference is Vault's own sealing, not a stated backup-encryption control. A referenced standalone "Backup Policy" doc doesn't exist in the repo (only cross-references). At least one MongoDB restore automation script is flagged as "not tested and may have errors on first run." Self-hosted: backup/DR is entirely customer-managed - explicitly excluded from Appcircle's DR Plan and retention policy. Sources: disaster-recovery-plan business-continuity-and-disaster-recovery-policy data-retention-and-disposal-policy hosting-options
PR.IP-5: Do you have tools and procedures to securely erase data?	Yes, at the policy level (Data Retention and Disposal Policy) plus customer-facing deletion features, though specific tool names are not published. Disposal methods per medium: Cloud - cloud-native deletion + cryptographic erasure per NIST SP 800-88 On-prem - secure overwrite, cryptographic erasure, or physical destruction Endpoint devices - secure wipe / factory reset before reassignment; remote wipe on loss/theft; all sensitive data + credentials erased before disposal Physical media - cross-cut shredding or certified destruction via vetted vendors Backups - disposed at next rotation aligned to source-data retention SaaS/third-party - deletion via built-in capability or API, verified against vendor practices; vendor contracts require data return/deletion on termination Standards - SOC 2, ISO 27001:2022, ISO 27701:2019, GDPR, KVKK; NIST SP 800-88 for cloud disposal. Data-subject erasure (GDPR/KVKK) - right to erasure, restriction, and portability, fulfilled within legally required timeframes via a Data Protection Contact role. Account deletion is staged (24h deactivation -> permanent deletion) with a deletion confirmation on request. Enterprise orgs get configurable per-module retention/auto-deletion; an Artifacts Report logs deletions including a "Physically Delete" flag. Responsibility - Engineering Management owns the policy; Engineering/Platform/Operations executes deletions and maintains disposal logs; disposal is stated to be logged and auditable. Legal holds override normal disposal. Honest caveats: Self-hosted is excluded - data lifecycle there is entirely the customer's responsibility; the only self-hosted guidance is operational (kubectl delete namespace), with no NIST-800-88/crypto-erasure procedure documented. No specific tool names documented (MDM wipe tool, KMS key-deletion API, shredding vendor) - only method categories. No explicit crypto-erasure procedure for backups and no detailed third-party deletion verification method. The referenced standalone "Data Protection Policy" and the detailed retention schedule are maintained separately, not in these docs. Sources: data-retention-and-disposal-policy endpoint-device-security-policy delete-account retention-period
PR.IP-8: Do you have a documented and tested Incident Response plan?	Yes to documented; testing is a documented commitment but I found no evidence it has actually been exercised. Documented IR plan - a standalone Incident Response Plan (effective 2026-02-05, owned by Engineering Management). Scope covers all Appcircle systems/personnel and third parties processing data where contractually applicable. Full lifecycle/phases - Preparation -> Identification & classification -> Containment -> Eradication -> Recovery -> Closure & post-incident review (root-cause + detection-coverage assessment). Severity - assessed on data sensitivity, users/systems affected, escalation risk, reputational impact. (Minor inconsistency: real IRs use a SEV-1/2/3 scale while the template still lists P1-P4 - the template is out of sync.) Roles - Engineering Management (final decisions, external comms), Engineering/Platform/Operations (leads containment/eradication/recovery), all personnel report incidents; an Emergency Response Team is referenced but not enumerated (detailed runbooks/contact lists kept separately). Breach notification - explicitly documented: GDPR Art. 33 (72h to supervisory authority), Art. 34 (affected data subjects), KVKK Art. 12 equivalent. Aligned to SOC 2 and ISO 27001:2022 A.5.24-A.5.28. Real incident archive - a substantive, real IR record set exists: 13 incidents (IR-0001 to IR-0013, 2025-09 to 2026-07), all Resolved, following a rigorous structure (root-cause, timeline, CAPA, a data/privacy impact assessment, sign-off). Note: all are operational/availability incidents; none is flagged as a personal-data breach, and no actual GDPR/KVKK notification was triggered in any of them. Honest gap - testing: the plan states IR plans are "tested at least annually" (tabletop, walkthrough, simulation, or third-party assessment), but I found no record, date, or report of an actual IR test having been performed - no "last tested" date, no post-exercise findings. Contrast this with the Disaster Recovery Plan, which does have a concrete conducted-test cadence and real simulation scripts. So: IR testing is a documented commitment, not documented as actually exercised. Worth flagging in a compliance context. Sources: incident-response-plan index disaster-recovery-plan
PR.PT-1: Are audit records determined, documented, implemented, and reviewed in accordance with policy?	Partially. Audit records are determined, documented, and implemented per a policy; the "reviewed in accordance with policy" part is required on paper but the specific cadence/retention are not documented in the accessible docs. Policy exists - the Logging and Monitoring Policy (effective 2025-04-10, reviewed 2026-02-05, owned by Engineering Management), itself on an annual review cycle. What's logged - explicitly enumerated: authentication/session events (logins, MFA, token issuance), authorization/privilege changes, administrative actions (account lifecycle, config changes), sensitive-data access/modification, infrastructure/deployment activity, and security events including secret and key access and vulnerability scan results. Content fields - timestamp (UTC), event type, source system, actor identity, action, outcome, source network address; time-synchronized clocks; no plaintext credentials/PII. Protection - access restricted need-to-know; admin log access itself logged; separation of duties (admins can't erase their own activity logs); integrity/change-detection mechanisms; logging-config changes under change management. Centralization - logs forwarded to a centralized platform, encrypted in transit. Concrete implementation: SigNoz + ClickHouse for the runner/agent fleet (ADR-0019, live 2026-07), alongside a Grafana+Loki stack. Monitoring/alerting - covers security anomalies, IOCs, and critical-control failures, routed to on-call with periodically tuned rules. Honest gaps (both explicitly deferred to unpublished "internal standards"): Retention period - not documented. The policy states retention is "defined based on regulatory/contractual/operational requirements" and "documented in internal standards," but no number is given. (One narrow exception: privileged VM session recordings have a documented 90-day minimum.) Note ADR-0019 lists log retention/VM sizing (PL-188) as an open, unfinalized follow-up. Log review actually performed - not documented. The policy requires review "on a regular, defined schedule," but names no cadence and no specific reviewing role, and I found no records/findings/tickets evidencing executed reviews. So the requirement exists; evidence that reviews are actually conducted, and their frequency, is not in these docs. Sources: logging-and-monitoring-policy data-retention-and-disposal-policy 0019-observability-visualization-backend-signoz
PR.PT-6: Have you disabled any unused feature in an effort to harden your IT systems?	Yes, disabling unused features/services/ports is documented across several concrete hardening artifacts, though there's no single unified hardening standard. Concrete hardening evidence: VM/LXC security standard - the closest to a baseline: no root SSH, SSH off port 22, PasswordAuthentication no, MaxAuthTries 3, X11/TCP forwarding off, and an explicit "only required ports must be opened / internal services not exposed publicly" rule, with a minimum baseline checklist. Default-deny networking - Proxmox cluster firewall policy_in=DROP/policy_forward=DROP with only specific ports allowed; it explicitly disables a duplicate legacy service (pve-firewall.service stopped/disabled). Teknotel FortiGate uses explicit allow-list + implicit deny, with a checklist flagging an unused VPN?LAN rule for disabling. macOS runner host hardening (harden-macos-host.sh, CIS macOS L1 subset) - disables Remote Management, File Sharing, Printer Sharing, Remote Apple Events, Internet Sharing, Bluetooth, the guest account, and analytics/Siri daemons; enables firewall + stealth mode. The ephemeral build-VM script (TDD-0011) additionally disables telemetry daemons, Spotlight indexing, Time Machine, and auto-update scanning. Minimal/hardened images - backend services build on a chiseled distroless base with per-build Trivy scans; a prod-ready LXC template installs a minimal package set (--no-install-recommends) for "minimal attack surface"; Keycloak image-hardening initiative (ADR-0011). Minimal ports for self-hosted - customers instructed to open only 80/443 (or 80/6379), nothing more. Honest gaps: No single unified system-hardening standard spanning OS/network/container/app - coverage is per-layer. No documented control for "debug code disabled in production" - searches found nothing on this. No documentation of removing default/test accounts within the Appcircle application/server itself (infra account model and macOS guest account are covered, but not the product). The CodePush standalone server explicitly disclaims hardening as "customer's responsibility." Sources: security-standard network-firewall macos-host-hardening 0011-harden-guest-script backend-service-release
PR.PT-7: Do you have IT network protection and control technologies and processes?	Yes, spanning a governing policy plus concrete technologies and processes across edge, cloud, and host layers. Governing policy - Network Security Policy (owned by Engineering Management, effective 2026-02-05, reviewed at least annually). Principles: encryption by default, least exposure, layered controls, environment isolation. Firewall/NSG changes go through the Change Management Policy and are logged as administrative actions (infra managed as code, peer-reviewed, dev?test?prod promotion). Firewalls - edge NGFW (FortiGate 3200F at Teknotel, explicit-allow/default-deny with implicit deny); GCP VPC firewall rules restricting traffic to explicitly permitted flows; host firewalls (SSH restricted to Guacamole source IP; Proxmox four-layer design with cluster default-deny). Segmentation - GCP VPC isolation between environments (prod separated from dev/test at project/namespace level); OVH/Proxmox SDN zones; FortiGate zone segmentation (LAN/WAN/VPN). WAF - active in production (handles global IP throttling in cloud; confirmed operational via incident IR-0004). DDoS - Cloudflare provides network-layer DDoS mitigation for public-facing services. VPN / remote access - site-to-site IPsec tunnels for customer connectivity; internal infra access via SSO-gated Guacamole bastion with session recording. Note: no corporate VPN for general remote-workforce access is documented (only a WPA2+ Wi-Fi requirement). TLS - minimum TLS 1.2 between all services and users; AES-256; unencrypted protocols not permitted for sensitive data. Rate limiting - two layers: a global IP layer (disabled in cloud, where the WAF handles it) and Ocelot gateway per-user/org/IP policies. Honest gap - IDS/IPS is NOT documented as implemented. It appears only as (a) a generic FortiGate capability not actually enabled on any documented rule (all rules use no-inspection or certificate-inspection, i.e. no UTM/IPS scanning), and (b) an abstract control category in the Logging & Monitoring Policy. Treat IDS/IPS as unconfirmed/not deployed. Detailed cipher suites, firewall rulesets, and segmentation architecture are kept in separate internal standards. Sources: network-security-policy network-firewall firewall rate-limit

NIST CSF - Detect

Question	Answer
DE.AE-2: Do you analyze detected security events to better understand new potential attack targets and methods?	Partially. Appcircle analyzes security events and feeds findings back into controls, but there is no dedicated threat-intelligence program in the "understand new attack targets and methods" sense. What is documented and practiced: Log review for trends/anomalies/IOCs - the Logging and Monitoring Policy requires monitoring for security anomalies (unusual auth patterns, unauthorized access, privilege escalation, indicators of compromise), and that security-relevant logs are "reviewed on a regular, defined schedule to identify trends, anomalies, or indicators of compromise," with findings documented and escalated to incident response. Post-incident root-cause analysis feeding back into controls - the IR plan's closure phase requires identifying root causes, assessing whether monitoring/detection coverage was adequate, and implementing improvements to prevent recurrence. Actually executed, not just policy - the IR archive shows the loop in practice: IR-0001 has a full Root Cause Analysis, a 12-item Corrective & Preventive Actions (CAPA) table across four defense layers, and a Lessons Learned section feeding a detected monitoring gap into a new control. This structure is template-driven (standard, not one-off). Honest gaps: No dedicated threat-intelligence function - no standalone threat-intelligence policy, no process for consuming external threat feeds or analyzing adversary TTPs/IOC feeds to anticipate new attack methods, and no described anomaly-detection or threat-hunting program beyond the general log-review language. ISO 27001 A.5.7 (Threat intelligence) is cited for regulatory alignment in the Risk Assessment Policy but not operationalized in the text - it's a control-mapping citation, not a described program. The one threat-intel analysis on record (IR-0001) is analysis of a third party's threat-feed action affecting Appcircle, not Appcircle analyzing attackers against its own environment. Sources: logging-and-monitoring-policy incident-response-plan 0001-ir-2026-0224 risk-assessment-policy
DE.CM-1: Is your network monitored to detect potential cybersecurity events?	Yes, monitoring exists and is committed to at policy level, with real alerting shown in practice, but most evidenced monitoring is availability/performance rather than dedicated security-event detection, and there is no NIDS/NIPS implemented. Committed to (Logging and Monitoring Policy): detection of security anomalies (unusual auth patterns, unauthorized access attempts, privilege escalation, IOCs), availability/performance issues, infrastructure health, and critical security control failures - all routed to on-call for response. This is a requirements-level statement. Tooling actually documented: GCP-native monitoring/alerting + uptime checks - the tooling shown firing in a real incident (IR-0004 detected via GCP Uptime Monitoring + a GCP alert on liveness-probe failures / HTTP 500s). SigNoz + ClickHouse - the runner/agent observability backend, but explicitly performance/fleet-health, not security-event monitoring; Grafana+Loki kept separate, no security use documented. WAF - handles IP throttling in front of the gateway, with a real rate-limit incident logged. Firewall logging - Proxmox default-deny with per-rule logging; FortiGate edge logging (though several sensitive inbound SSH/VNC admin rules currently have logging disabled - a flagged gap). Alerting/on-call - critical alerts routed to on-call; culture docs describe an S1-S3 severity process with an Incident Commander and a rotation. Honest gaps: No dedicated network IDS/IPS implemented - "intrusion detection/prevention" appears only as a control category to monitor for failure, with no named product, ruleset, or deployment. Also no named SIEM. Every concrete evidenced monitoring event was an availability/performance signal, not a security-anomaly detection; IR-0004 itself concludes it "did not constitute a security incident." Documented coverage gaps: IR-0002 states detection "relied entirely on customer reports" for 6 hours, with continuous synthetic monitoring still in Backlog; IR-0004 flags missing cloud-side WAF documentation. Detailed log-review cadence, retention, and security-monitoring tooling are deferred to unpublished internal standards. Sources: logging-and-monitoring-policy network-security-policy 0004-ir-2026-0407-testerweb-waf-rate-limiting 0002-ir-2026-06-09-cloud-runner-network-instability
DE.CM-2: Is your physical environment monitored to detect potential cybersecurity events?	Physical-environment monitoring is documented only for the cloud-delegated production infrastructure. For Appcircle-operated facilities (office, Teknotel colo, on-prem lab), CCTV/badge logs/alarms/environmental sensors are not documented. Environment: GCP production infra Operator: Google (delegated) Physical monitoring documented? Yes - delegated to Google: surveillance, access controls, environmental protection, media handling, evidenced by GCP's SOC 2 Type II report (reviewed under vendor management) Environment: Istanbul office Operator: Appcircle Physical monitoring documented? Access control + visitor acknowledgement only; no CCTV, badge logs, alarms, or power/cooling/fire monitoring documented Environment: Teknotel datacenter (colo) Operator: Teknotel / Appcircle equipment Physical monitoring documented? Remote-hands ticketing + network-link monitoring (PRTG) only; no CCTV, badge/visitor logs, alarms, or environmental sensor monitoring documented Environment: On-prem lab (5-6 hosts) Operator: Appcircle Physical monitoring documented? Existence documented; no physical/environmental monitoring documented So: Cloud (delegated): fully covered by Google - surveillance, environmental protection, and access controls, with SOC 2 Type II as the evidence Appcircle relies on. Appcircle-operated locations: the Physical Security Policy asserts access is "restricted to authorised personnel" with visitor acknowledgement, but describes no detective monitoring mechanism (CCTV, badge/visitor logs, intrusion alarms, or power/cooling/fire sensors). The policy itself flags that detailed internal office-access procedures are "maintained separately," so such controls may exist but are not in the documentation. Sources: physical-security-policy teknotel-ticketing-guide prtg 0004-virtualization-platform
DE.DP-1: Are roles and responsibilities for detection well defined for employees in order to ensure accountability?	Partially. Accountability is anchored at a functional/team level, but not decomposed into named detection roles - and some operational specifics an auditor would expect are deferred to unpublished internal standards. Clearly defined: Duty to report - consistently across four policies (Logging & Monitoring, Incident Response, Information Security, Acceptable Use): all personnel must promptly report suspected incidents, weaknesses, logging gaps, or anomalous activity through approved channels, routed to Engineering Management. Accountable owner - Engineering Management (Security Program Owner) owns each policy and makes final decisions on major incidents. Monitoring/detection execution - assigned to Platform / Operations ("implements and operates logging and monitoring infrastructure; manages retention, access controls, and alerting"); engineering teams ensure apps emit required log events. On-call / Incident Commander - defined (single Incident Commander owning communication/coordination, engineers handle technical response, S1-S3 response times), and an Emergency Response Team for major incidents. Honest gaps: No named/dedicated detection role or team - no "SOC," "Detection Analyst," "Security Engineer," or "Security Lead" title is staffed anywhere in the corpus; responsibility stays at the coarse "Platform/Operations" level. Log-review ownership - the policy says review happens "on a regular, defined schedule" but names no specific reviewer role or cadence; both are deferred to unpublished internal standards. Role fragmentation - the Incident Commander (culture handbook) and Emergency Response Team (BCP policy) are defined in separate documents, not cross-referenced from the Incident Response Plan's own roles section, and their relationship isn't reconciled. RACI matrix - only the authoring methodology is in the docs; the actual task-level R/A/C/I assignments for detection activities live in an external Excel file not in the repo, so they couldn't be verified. Sources: logging-and-monitoring-policy incident-response-plan acceptable-use-policy responsibility-matrix

NIST CSF - Respond

Question	Answer
RS.CO-1: Are roles and responsibilities clearly defined for cyber Incident Response?	Partially. Roles are defined at a role/tier level across the governance docs, but at named-individual level they're not published, and there are some unreconciled inconsistencies worth flagging. Clearly defined (Incident Response Plan roles): Engineering Management (Policy Owner) - accountable; ensures readiness/review; "makes final decisions on major incidents and external communications." Engineering / Platform / Operations - implements and coordinates the response; leads containment, eradication, recovery. All personnel - promptly report suspected incidents through approved channels. Incident Commander (culture handbook) - single commander owning communication/coordination, engineers handle technical response, decides when to escalate, owns customer comms; with S1-S3 response-time targets and an on-call rotation. Emergency Response Team (BCP policy) - activates/coordinates BCP-DR, coordinates technical response + stakeholder comms + service restoration, runs retrospectives. Breach notification - GDPR Art. 33/34 and KVKK Art. 12 obligations and timelines documented. Honest gaps: Incident Commander vs ERT not reconciled - two documents define two different single-point coordination roles with no cross-reference explaining how they relate. Internal inconsistency on external-comms authority - the IR Plan's Roles section gives final external-communication decisions to Engineering Management, while its own Stakeholder Communications section gives that to the ERT. ERT membership/contact lists not published - the BCP policy itself states ERT contact details and roles are "maintained separately" in internal documentation, not present in the docs. No named responders or contact list anywhere in the searched docs (governance, operations, people-access). No role explicitly assigned to file/sign the regulatory breach notification beyond the general Engineering Management accountability. Sources: incident-response-plan business-continuity-and-disaster-recovery-policy culture
RS.CO-2: Do you have a clear communication plan in case of cyber incidents?	Partially. There's a documented communication framework and a real practice of logging communications, but not a single formal communication plan with predefined channels, templates, and a verifiable contact list. Documented framework: ERT owns communication decisions - the IR Plan assigns the Emergency Response Team the timing, scope, and content of communications, weighing whether disclosure could worsen the incident, affected-party needs, regulatory timelines, and informing internal staff before any public statement; all decisions documented for retrospective review. Regulatory/breach notification - GDPR Art. 33 (72h to supervisory authority), Art. 34 (affected data subjects), KVKK Art. 12 equivalent, with timelines and legal triggers. Leadership updates - the DR Plan has a concrete cadence for major events: leadership notified within 30 min, customer progress updates every 2-4h via status page + Slack, resolution report within 96h. Communication logs actually exist - six real IRs include a Communication Log table (date/time/channel/audience/summary), with Slack as the consistent internal channel. Honest gaps: Ownership inconsistency - policy gives final say on external comms to Engineering Management, but a second IR Plan section gives it to the ERT, and in practice CSM/customer-facing teams led customer notifications. Not reconciled. No external templates - two separate retrospectives (IR-0001, then IR-0002 four months later) recommend creating pre-drafted customer notification templates and a SEV-2 comms SLA - confirming they didn't exist and, as of the later incident, still weren't delivered. No maintained/committed contact list - both policies say contact lists are "maintained separately" outside the docs; not verifiable. No regulatory-notification owner or tracking field - no DPO/Legal role named for GDPR/KVKK filing; the IR template has no field for it, and no IR in the archive records an actual notification being triggered (so the 72h process isn't evidenced as exercised). Inconsistent response speed - customer notification ranged from same-hour to ~6 hours to none, by varying channels. The concrete customer-comms cadence lives only in the DR Plan (major/BCP events), not the general IR Plan that governs the common SEV1-3 incidents. Sources: incident-response-plan disaster-recovery-plan 0001-ir-2026-0224 0002-ir-2026-06-09-cloud-runner-network-instability
RS.AN-3: Are processes established to receive, analyze and respond to vulnerabilities disclosed to the organization from internal and external sources (e.g. internal testing, security bulletins, or security researchers)?	Yes, a documented process exists (Vulnerability Management Policy, effective 2026-02-05), covering both internal and external sources, with a couple of documentation gaps to flag. Internal identification - all documented: secure-development training, peer code review (also in SDLC Policy), third-party SAST/vulnerability scanning (backed by a real SAST program - dated scan reports with findings classified Valid / False Positive / Risk Accepted / Fix Required), and annual third-party penetration testing. External sources: Public disclosure contact exists - a live RFC 9116 security.txt (Contact: mailto:security@appcircle.io, links the Information Security Policy, expires 2027-07-18). Note it lives in the appcircle-website repo, not the docs sites. Security researcher / third-party reports - the IR Plan names "third-party notification" and "customer reports" as identification channels. Dependency scanning - covered generically, plus one concrete record (Dependabot + pip-audit findings on ac-service-mcp). Triage - five-tier severity (Urgent/Critical/High/Medium/Low) assessed on likelihood × impact. Remediation SLAs - Urgent 1 day, Critical 3 days, High 30 days, Medium 90 days, Low best-effort. Tracking - all vulnerabilities logged and tracked to resolution (title, description, assessed impact). Honest gaps: Responsible Disclosure Policy is referenced but not present - the Information Security Policy names it twice, but no such document exists in either docs tree; it exists only as a named reference. And no docs-site page surfaces a "report a vulnerability" process for external researchers. Security-bulletin / third-party CVE-advisory monitoring is not documented - no procedure describes ingesting CVE feeds or vendor advisories; only generic "third-party scanning tools," plus the one isolated Dependabot record. (ISO 27001 A.5.7 Threat Intelligence is cited for alignment but not operationalized.) Sources: vulnerability-management-policy sdlc-policy sast-index information-security-policy
RS.MI-2: Do you have processes and tools to mitigate security incidents?	Yes, both processes and (general infrastructure) tools, evidenced in policy and in real incidents, though not via dedicated IR-automation tooling. Process - the Incident Response Plan defines a six-stage lifecycle (Preparation -> Identification -> Containment -> Eradication -> Recovery -> Closure/review). Containment explicitly names isolating/shutting down compromised systems, removing/restricting access to exposed data, and temporary config changes, with high-severity incidents proceeding "directly to containment without delay." Eradication covers root-cause fix, malware removal, credential revocation, verified before recovery. Mitigation levers actually used (from real IRs): Credential rotation - IR-0009 (storage 401, SEV-1) resolved by refreshing/rotating storage credentials in ~90 min. Halting exposure - IR-0005 (dSYM deletion) rollout proactively halted. WAF exception - IR-0004: an internal-IP WAF rate-limit exception added same-day (CAPA-01, Done). Rollback - IR-0010 resolved via version rollback; Change Management Policy defines an Emergency Changes process (management approval, retrospective doc, post-implementation review). DR for recovery - RTO <16h / RPO <24h, daily backups, and DR activation criteria explicitly include "security incident requiring full environment isolation and rebuild." CAPA tracking - IRs carry formal Corrective & Preventive Action tables with owners/status (IR-0001 has 12 items across four defense layers), showing findings feed back into controls. Honest gaps: No published S1/S2/S3 response-time SLA - severity is used as a classification label but no hour/minute containment targets per tier are documented. (The time-bound SLAs that exist are for vulnerability patching, not live incidents - don't conflate.) No named dedicated IR/containment tooling (SOAR, EDR isolation, IR automation) - mitigation relies on general infra controls (WAF rules, GCP monitoring, Vault/KMS secret rotation, K8s/Helm redeploy, DNS workarounds, version rollback). If specialized tooling exists, it's not documented. Detailed internal runbooks, escalation paths, contact lists, and rollback configs are explicitly kept separate, not in these docs. Sources: incident-response-plan disaster-recovery-plan change-management-policy 0004-ir-2026-0407-testerweb-waf-rate-limiting

NIST CSF - Recover

Question

Answer

RC.CO-3: Are recovery activities communicated to internal and external stakeholders as well as executive and management teams?

Yes for formal DR-level events, where cadence and audiences are explicitly defined; for general incidents it's real but ad hoc, and some documented mechanisms aren't yet evidenced in practice. Documented (Disaster Recovery Plan §8 communication table, on DR activation): Detection -> internal engineering (incident channel), immediate Activation -> leadership + Engineering Management, direct notification within 30 minutes Progress updates -> affected customers, status page + customer Slack, every 2-4 hours during recovery Resolution -> all stakeholders, post-incident report via status page + customer Slack, within 96 hours Engineering Management owns stakeholder communication; the Emergency Response Team provides "regular updates to leadership and affected parties during a major event" and runs the retrospective. Real incident evidence (Communication Logs): IR-0001 (SEV-1) - customer notified mid-incident and again at resolution ("service restored to normal operation") IR-0002 (SEV-2) - resolution communicated across community + 7 enterprise + cloud support channels, plus a next-day stability briefing to a named leader IR-0004 (SEV-3) - internal Slack update + direct status DM to the CEO Honest gaps: The defined cadence/audience table exists only for formal DR activation, not general incidents - the Incident Response Plan leaves timing, scope, and audience to ERT discretion case-by-case. No sampled incident was an actual DR activation, so the DR Plan's specific cadence (30-min leadership, 2-4h customer updates, 96h post-incident report) has no real-world evidence of ever being exercised. Status page is asserted in policy but never evidenced - all real customer comms used Slack only. No formal customer-facing post-incident report published within 96h in the sampled incidents (IR write-ups are marked internal-only). Leadership notification is ad hoc for general incidents (CEO DMs, morning briefings), not the DR Plan's timed standard, and a SEV-severity customer-notification SLA still doesn't exist (IR-0002's CAPA-05 for it remains Backlog). Sources: disaster-recovery-plan incident-response-plan 0002-ir-2026-06-09-cloud-runner-network-instability 0004-ir-2026-0407-testerweb-waf-rate-limiting

General Security Questionnaire

Question	Answer
Does your company have a dedicated Information Security Officer? (Yes or No)	No
Who in your organization signs off on information security policy?	Engineering Management (as "Security Program Owner") is the documented owner and accountable party for the Information Security Policy - but there is no formal named sign-off/approver in the documents. Being precise: The policy names only a role: "Policy owner: Engineering Management (Security Program Owner)," who "owns this policy, ensures it is reviewed, updated, and communicated." Every governance policy uses this identical pattern. The document has "Effective date" and "Last reviewed" fields (both 2026-02-05) but no separate "Approved by," "Signed off by," or "Approval date" field, and no specific individual or executive title (CEO/CTO) is captured as approver. The only explicit "approval" language applies to policy exceptions ("approved by the policy owner or an authorized delegate"), not to issuance of the policy itself. The Responsibility Matrix guidance notes "CTO may be the ultimate executive owner... for strategy-level decisions or risk acceptance," but the actual RACI sign-off assignments live in an external SharePoint Excel file not in the docs, so a specific named approver can't be verified from documentation. So: accountability sits with Engineering Management as a role; a formal named executive sign-off is not documented in these docs. Sources: information-security-policy responsibility-matrix
Does your company have a dedicated team that governs and enforces an information security program that is aligned with industry standards? (Yes or No)	Qualified Yes - with one honest caveat on "dedicated team." Appcircle does govern and enforce an information security program aligned to industry standards: a full set of governance policies owned by Engineering Management (Security Program Owner), mapped to SOC 2, ISO/IEC 27001:2022, GDPR, and KVKK, with enforcement mechanisms (peer review, access reviews, SAST, vulnerability SLAs, incident response). The caveat: it is not a dedicated standalone security team or CISO. Program ownership sits with Engineering Management as a function, executed by Engineering/Platform/Operations, with a @team/security referenced in the RACI matrix. So if "dedicated team" strictly means a separate, staffed security department, that specific structure is not documented. Sources: information-security-policy responsibility-matrix
What framework do you use for Security Controls? COBIT, NIST, ISO 27001, HITRUST etc	Based on the governance docs (consistent across every policy's "Regulatory alignment" section): Primary frameworks Appcircle's controls are built around: ISO/IEC 27001:2022 - the core framework; specific Annex A controls cited per policy (e.g. A.5.15-A.5.18 access control, A.8.8 vulnerability management, A.8.25-A.8.31 secure development, A.5.24-A.5.28 incident management, A.7 physical, A.8.20-A.8.23 network). The Risk Assessment Policy states directly: "Appcircle uses a risk-based approach... consistent with ISO/IEC 27001 and aligned with SOC 2 requirements." SOC 2 (Trust Services Criteria) - cited across nearly every policy. Also referenced: ISO/IEC 27701:2019 (privacy management extension) - in the data disposal policy NIST SP 800-88 - specifically for media sanitization / secure erasure (not NIST CSF or 800-53 as a controls framework) GDPR and KVKK - regulatory/privacy obligations, not control frameworks per se Not used / not documented: COBIT, HITRUST, and NIST CSF / NIST 800-53 as control frameworks are not referenced anywhere. So the short answer: ISO 27001:2022 + SOC 2 as the governing control frameworks, with ISO 27701 and NIST SP 800-88 for specific domains. Note the docs describe controls as aligned to/consistent with these frameworks rather than asserting a current certification/attestation (the only cited third-party SOC 2 Type II evidence is for GCP as infrastructure provider). Source: information-security-policy
Please provide any Security Documentation or attestations of your security environment. This could include an ISO Certfication, SOC2, etc.	ISO Certification and SOC 2 Type 2 certification available.
Describe any screening activities performed for job applicants and contractors (e.g., criminal background, drug use, credit checks, qualifications, references)	Screening is only partially documented, and the specific check types are not spelled out in the accessible docs. What is documented: An "Employee Background Check Policy" is named as a supporting policy in the Information Security Policy - but the actual policy document (its methods/content) is not present in the docs; only the title is referenced. The onboarding checklist includes a background-check step, worded conditionally: "Background check (if applicable)" / "if required for the role." It sits under the onboarding "Training and orientation" step, as a tracked item. The Information Security Policy's scope covers "employees, contractors, and temporary staff." What is NOT documented (explicitly absent): No specific check types - criminal background, credit checks, drug/substance testing, education/qualification verification, employment/reference checks, and identity verification are none of them named or described anywhere in the docs. Contractors - covered by policy scope generally, but no doc states whether contractors specifically undergo a background check. Timing - the step is an onboarding activity; no doc uses "pre-employment" or specifies completion before offer/start date. No vendor/provider, jurisdiction process, or handling/retention rules for results. So: a background-check step and a named policy exist, but the substantive detail (what's checked, contractor inclusion, pre-employment timing) is maintained outside these docs and can't be stated from the documentation. Sources: onboarding information-security-policy
Are employees required to sign a confidentiality or non-disclosure agreement as part of their initial terms and conditions of employment? (Yes or No)	Yes for NDA
Are employees trained on how to label and properly handle confidential information? (Yes or No)	Partial - so honestly a qualified Yes, but with an important gap. What's documented: A data classification scheme with labeling tiers exists (Restricted / Confidential / Internal / Public) with explicit handling rules. All personnel must read, acknowledge, and adhere to the classification policy and handle data per its classification. General security/compliance awareness training is required at onboarding (SOC 2, KVKK, GDPR awareness), plus mandatory information security awareness training per the Acceptable Use Policy. The gap (why it's only qualified): No document explicitly states that the training curriculum covers data classification, labeling, or handling as a topic. The onboarding checklist lists SOC 2 / KVKK / GDPR training and "review company policies" as separate items, but nowhere says labeling/classification is taught as training content vs. just being a policy employees must acknowledge. No annual recurring training requirement for data classification/handling. The only documented annual training requirement is developer secure-coding training (OWASP Top 10) under the SDLC Policy. So: a classification policy and general awareness training both exist, and employees must acknowledge the handling rules - but explicit, dedicated training on labeling/classification specifically (and any annual cadence for it) is not documented in these docs (detailed training procedures are noted as maintained separately). Sources: asset-management-and-data-classification-policy acceptable-use-policy sdlc-policy onboarding
Is information security training require for each employee?	Yes, information security training is required, though the documented cadence differs by role. Required for all personnel: At onboarding - security and compliance training (SOC 2 awareness), plus KVKK and GDPR awareness training, with completion documented (date + confirmation). The Acceptable Use Policy requires every employee/contractor/applicable third party to "complete mandatory information security awareness training" and to read/acknowledge/accept the policy. Annual, but role-scoped: The SDLC Policy mandates annual security training for anyone writing or supporting code for customer-facing or internet-exposed applications, including OWASP Top 10 awareness. This annual cadence is explicitly tied to developers, not to general staff. Honest nuance: onboarding security-awareness training is required org-wide, but the docs do not document a general annual/recurring awareness-training requirement for all employees - the only explicit annual training requirement is the developer secure-coding one. Detailed training programs are noted as maintained separately. Sources: acceptable-use-policy sdlc-policy onboarding
What topics are included in the information security training and how often is training repeated?	Here's what's documented, split by audience and cadence. Org-wide onboarding training (one-time, at hire) - all personnel: Security & compliance training (SOC 2 awareness) KVKK (Türkiye data protection) awareness GDPR (EU data protection) awareness Company policy / employee handbook review General mandatory information security awareness training (per Acceptable Use Policy - no topic breakdown given) Endpoint/device security awareness (communicated at onboarding + "periodic management review") All documented with completion recorded (date + confirmation). Role-specific developer training - annual, recurring: OWASP Top 10 awareness + secure development principles - required annually for anyone writing/supporting code for customer-facing or internet-exposed applications (SDLC Policy). This is the only explicitly documented recurring cadence. Secure coding practices (Vulnerability Management Policy) as a developer duty. How often is it repeated? Developers: annually (secure coding / OWASP). General staff: the org-wide topics are documented only as one-time onboarding items. Endpoint training is tied to "periodic management review" but "periodic" is not defined as annual or any fixed interval. No document specifies a recurring/annual awareness-training cadence for general (non-developer) staff. Topics NOT documented as training (honest gaps): phishing (only a reporting duty), data classification/labeling, and incident reporting (behavioral duties, not named training topics). Detailed training programs are noted as maintained separately. Sources: onboarding sdlc-policy acceptable-use-policy endpoint-device-security-policy
Describe your security measures for access to offices and sensitive areas. Are access badges required? Are there cameras at entrances? Etc.	Physical security for Appcircle-operated offices is documented only at a high level, and specific measures like access badges and cameras are not documented. What is documented (Physical Security Policy): Appcircle is predominantly remote, with a single Istanbul office used on a limited/flexible basis. Access control - "Access to the office is restricted to authorised personnel. Visitor access requires acknowledgement at reception or equivalent escort controls." Clean desk - sensitive information not left unattended or visible. Secure storage - physical documents with sensitive info kept in locked storage. Asset protection - Appcircle devices not left unattended/unsecured in the office or in transit. Incident reporting - suspected unauthorized physical access, loss, or theft reported to Engineering Management immediately. What is NOT documented (explicit gaps): Access badges - no badge/keycard system is mentioned anywhere for the office. Cameras / CCTV at entrances - not documented. Intrusion alarms, visitor logs (retained), environmental sensors - not documented. The policy itself flags that detailed internal office-access procedures are "maintained separately and may be shared under appropriate agreements" - so such controls could exist but are not in the documentation. Sensitive areas / data centers - Appcircle stores no sensitive production data on-premises; production runs on GCP, whose data-center physical controls (surveillance, access control, environmental protection) are delegated to Google and evidenced by GCP's SOC 2 Type II report. Note: Appcircle also operates hardware at a Teknotel colocation facility and an on-prem lab, but no CCTV/badge/alarm controls are documented for those either (only remote-hands ticketing and network monitoring). So: badges and entrance cameras are not documented for Appcircle offices; access is controlled via "authorised personnel only" + visitor acknowledgement/escort, and data-center physical security is delegated to GCP. Sources: physical-security-policy 0004-virtualization-platform
Are there documented procedures for labeling and handling confidential information based on a standardized classification scheme? (Yes, No, or N/A)	Yes. The Asset Management and Data Classification Policy defines a standardized four-tier classification scheme - Restricted, Confidential, Internal, Public - each with examples, plus a "Data handling requirements" section (sensitive data restricted to approved storage, not stored on end-user devices, management approval required before public disclosure, treat as confidential when in doubt). Retention and secure disposal are tied to this classification. One honest nuance: the policy documents the scheme and handling rules, but the more granular internal handling procedures are noted as "maintained separately." And as covered earlier, explicit training on labeling/classification isn't documented (the classification policy exists and must be acknowledged, but it's not named as a training topic). Source: asset-management-and-data-classification-policy
Please explain your standards for handling confidential data or explain why if you selected N/A for AM.1.	I answered Yes to the prior question, so here are the confidential-data handling standards, grounded in the Asset Management and Data Classification Policy plus supporting policies. Classification scheme (four tiers): Restricted (most sensitive, strict need-to-know) -> Confidential (non-public business info incl. customer data/PII, contracts) -> Internal (employees/approved stakeholders only) -> Public. "Sensitive" = all non-public categories. Core handling rules (for sensitive/confidential data): Collected only when there's a legitimate business need (minimization) Security and confidentiality protected by default unless explicitly approved otherwise Restricted to approved, secure storage locations; must not be stored on end-user/local device drives Management approval required before making any sensitive data public, and before disclosing/sharing confidential Appcircle/customer information Backed up regularly to separate, secure locations Access control: least privilege ("minimum level required... no excess permissions by default") and need-to-know ("access to sensitive data restricted to those with a documented business need"). Encryption: data protected in transit and at rest ("encryption where appropriate"); databases with non-public data require encryption at rest; full-disk encryption (FileVault/BitLocker) on all devices; no unencrypted Wi-Fi for business use. Retention & secure disposal (classification-driven): retention periods and disposal methods determined by classification, stronger methods for higher sensitivity - cloud-native deletion + cryptographic erasure per NIST SP 800-88, secure overwrite/physical destruction on-prem, secure wipe of devices, cross-cut shredding of physical media, API-based deletion for SaaS. Logging restrictions: logs must not contain plaintext credentials, unmasked card data, or PII beyond what's needed; log access restricted need-to-know; admins can't erase their own activity logs. Honest nuance: the tiers and the general handling/retention/disposal/logging principles are documented, but a granular per-tier matrix (exactly which storage systems, encryption standards, or retention-day counts apply to "Confidential" vs "Restricted" specifically) is explicitly "maintained separately" and not in the published docs. Sources: asset-management-and-data-classification-policy data-retention-and-disposal-policy system-access-control-policy logging-and-monitoring-policy
Do you maintain an asset inventory?	Yes. The Asset Management and Data Classification Policy states Appcircle "maintains an inventory of its key information assets," covering: People - HR employee list as authoritative record of who has access Endpoint devices - inventoried and managed Databases/data stores - production databases tracked (non-public data encrypted at rest) Source code repositories - in GitHub under access controls Software systems and documents/policies (reviewed at least annually) Supporting mechanisms: Lifecycle management - Endpoint Device Security Policy defines provisioning, lost/stolen handling (immediate remote wipe + access revocation), and secure disposal/decommissioning. Device tracking - onboarding requires recording ownership, serial numbers, and assignment; onboarding/offboarding checklists have Asset / Serial-ID tables. Vendor register - the Vendor Management Policy requires a register tracking each vendor's accountable owner, security accreditations, risk ratings, and review history. Honest caveats: The actual inventory register content is not in the docs - the policy explicitly states the asset inventory register, data-handling guidelines, and disposal processes are "maintained separately." Same for the vendor register content and device configuration baselines. The one place real asset data appears in-repo (completed offboarding checklists) is inconsistently filled - one confirmed device serial, several left blank. Mac inventory is a pointer to an external SharePoint spreadsheet, not an in-repo register. So: the requirement, scope, ownership, and lifecycle/tracking processes are documented; the populated inventory itself lives outside these docs and, where visible in-repo, is spottily maintained. Sources: asset-management-and-data-classification-policy endpoint-device-security-policy vendor-management-policy onboarding
Is there a formal change management process in place?	Yes. A dedicated Change Management Policy exists (effective 2026-02-05, owned by Engineering Management), aligned to SOC 2, ISO 27001:2022 A.8.32, GDPR Art. 25, KVKK Art. 12, backed by concrete release runbooks. Version control - all code changes managed in GitHub with full version history; changes tracked with enough context for retrospective review. Peer review/approval - "peer review and approval of code changes are systematically enforced"; SDLC Policy requires review by at least one person other than the author, knowledgeable in secure coding. CI/CD automated checks - Jenkins runs automated checks and orchestrates promotions; production release only after passing all required automated and manual checks. Backend pipelines add a Trivy security scan. Environment promotion - dev -> test (impact assessment, integration testing, review, approval) -> production. Concretely: develop?dev (auto), release/*?prep, master?prod, with manual promotion gates on component releases. Production approval - all production changes require human approval from an authorized environment owner; no unapproved automated updates. Emergency changes - defined process: management approval before execution, documented justification/scope, retrospective completion of skipped steps, post-implementation review; only where the Incident Response Plan requires. Separation of duties - dev/test/prod logically separated; production access provisioned explicitly, not inherited from a dev/test role. Honest gaps: Rollback procedures are not consolidated in the policy - the Change Management Policy explicitly defers detailed rollback procedures to separately maintained internal docs. Practical per-release guidance does exist (roll back by immutable tag, not force-push history). No Change Advisory Board (CAB) is documented anywhere - approvals run through management/authorized environment owners rather than a formal CAB (the RACI matrix content lives in an external Excel file not in the docs). Sources: change-management-policy sdlc-policy backend-service-release component-release
Do you have a formal separation of duties between development and production?	Yes, formally documented, though enforcement detail sits in separately maintained internal standards. SDLC Policy (the core statement): "Development, testing, and production environments are logically separated. Access to production is not granted by default as a consequence of a development or testing role; it is provisioned explicitly based on documented operational need, in accordance with the System Access Control Policy." Supporting controls: System Access Control Policy - "Separation of duties: Critical functions are divided across roles to reduce the risk of error or misuse," plus least privilege, need-to-know, and quarterly access reviews with heightened scrutiny for privileged access. Change control - all production changes require human approval from an authorized environment owner; no unapproved automated updates. Promotion runs dev -> test -> prod through the Jenkins pipeline, with peer review by someone other than the author. Environment isolation - enforced at the GCP project/namespace level, with VPC-level network isolation between environments (Network Security Policy). Production data - prohibited in dev/test by default; exceptional use needs management approval, anonymization where possible, and secure erasure after. Logging - separation of duties extends to logs: admins on production systems cannot erase or deactivate logs of their own activities. Honest caveat: the policies state the principle and the approval requirement, but the specific enforcement mechanics (who holds production access, privileged-access controls, approval workflows) are explicitly "maintained separately" and not in the published docs, so I can't evidence the actual production access roster from documentation. Sources: sdlc-policy system-access-control-policy change-management-policy network-security-policy
Are all endpoint laptops that connect directly to production networks centrally managed?	No centralized MDM is documented - but also, no endpoint connects directly to production networks. Two-part answer: 1. Endpoints are not centrally managed via MDM. The Endpoint Device Security Policy states plainly: "Appcircle manages endpoint devices through policy-based controls and employee compliance." No MDM platform (Intune, Jamf, Kandji) or device-compliance enforcement engine is documented anywhere. Entra ID appears only as the identity/SSO/MFA layer, not as an MDM. Requirements (full-disk encryption - FileVault/BitLocker/LUKS2, anti-malware, timely patching, screen lock) are policy-mandated and self-attested, verified via "periodic management review and onboarding verification" rather than automated enforcement. Remote wipe exists as a manual, incident-triggered procedure ("upon notification, remote wipe and access revocation procedures are initiated"), with no tooling named to execute it. BYOD is permitted for lightweight access only (MFA, screen lock, no local confidential data), "subject to compliance review." 2. But production access is well-gated - no direct endpoint-to-production connection. Access runs through a browser-based Apache Guacamole bastion: SSO (OIDC) authenticated, group-scoped connection profiles, VM passwords injected from OpenBao (never handled by operators), every session recorded with 90-day minimum retention, and explicitly "without needing a local SSH client or VPN." Production is separately VPC-isolated on GCP with default-deny firewall rules. So: the question's premise doesn't quite apply - laptops don't connect directly to production - but for the record, the endpoints reaching that gateway are not centrally/automatically managed. Detailed device baselines and compliance-check procedures are noted as maintained separately. Sources: endpoint-device-security-policy guacamole network-security-policy
Does sensitive or private data ever reside on endpoint devices?	Per policy, no: storing sensitive/customer data on endpoints is explicitly prohibited. The prohibition, stated in three policies: Endpoint Device Security Policy: "Sensitive and customer data must not be downloaded or stored on local device drives. Approved cloud storage services must be used for Appcircle business data." Asset Management and Data Classification Policy: "Sensitive data must not be stored on end-user devices." Acceptable Use Policy: same rule, plus for BYOD - "No confidential or customer data may be stored locally on BYOD devices." Production data is also prohibited in dev/test by default; exceptional use requires management approval, anonymization where possible, a separate data copy (explicitly no laptop copies of confidential production data), and secure erasure after use (SDLC Policy). Compensating controls if data does land locally: Full-disk encryption required on every device (FileVault / BitLocker / LUKS2) Screen lock + auto-lock; devices not left unattended Remote wipe and access revocation initiated on loss/theft/compromise Secure wipe of all sensitive data and stored credentials before disposal or reassignment Credentials stored only in the enterprise password manager (Vaultwarden), not locally Honest caveat: enforcement is policy-based and self-attested, verified via periodic management review, not via MDM or DLP tooling on endpoints (the only named DLP, Microsoft Purview, covers corporate email/collaboration, not endpoint file storage). So the rule is clear and encryption backs it up, but there's no documented technical control that prevents a user from saving sensitive data locally. Sources: endpoint-device-security-policy asset-management-and-data-classification-policy acceptable-use-policy sdlc-policy
Describe policies and procedures for protecting and controlling endpoint devices.	Here's the documented endpoint control set, from the Endpoint Device Security Policy plus the Acceptable Use and Physical Security policies. Device lifecycle Provisioning - company-issued devices are configured by Engineering/IT with required security controls pre-applied before issue; Engineering Management confirms new devices meet policy before granting access. Loss/theft/compromise - reported to Engineering Management immediately; remote wipe and access revocation initiated without delay. Disposal/reassignment - all sensitive data, files, and stored credentials completely erased via secure wipe; devices returned and decommissioned on separation. Technical requirements Full-disk encryption mandatory: FileVault (macOS, AES-XTS), BitLocker (Windows, AES-256), LUKS2 (Linux) Anti-malware active: XProtect/Gatekeeper (macOS), Defender (Windows), approved solution e.g. ClamAV (Linux) Timely OS/security patching; non-compliant devices may be restricted Screen lock with auto-lock enabled MFA on all system access via Microsoft Entra ID Data handling Sensitive/customer data must not be downloaded or stored on local drives; approved cloud storage only Credentials stored only in the enterprise password manager (Vaultwarden), never locally Devices not shared with anyone outside Appcircle Remote work & physical protection Devices physically secured when not in use; not left unattended in the office or in transit Encrypted Wi-Fi (WPA2+) required; public/unencrypted networks prohibited for business use BYOD - permitted only for lightweight access (e.g. communication tools), held to the same bar: MFA, screen lock, current OS, no confidential or customer data stored locally, subject to compliance review. Compliance verification - via "periodic management review and onboarding verification"; non-compliance reported to Engineering Management for follow-up. Aligned to SOC 2, ISO 27001:2022 A.8.1, GDPR Art. 32, KVKK Art. 12. Honest gaps: enforcement is policy-based and self-attested, not backed by MDM/automated compliance tooling (no Intune/Jamf/Kandji documented); remote wipe is a manual procedure with no named mechanism; detailed device configuration baselines and compliance-check procedures are maintained separately. One documented exception: datacenter Mac mini build hosts run with FileVault intentionally disabled (approved, scoped deviation - treated as infrastructure, not workstations). Sources: endpoint-device-security-policy acceptable-use-policy physical-security-policy macos-initial-setup-data-center
Is each user of any system that stores, processes or transmits data uniquely identified (i.e., no shared or group IDs)? (Yes, No, or N/A)	Here's the documented endpoint control set, from the Endpoint Device Security Policy plus the Acceptable Use and Physical Security policies. Device lifecycle Provisioning - company-issued devices are configured by Engineering/IT with required security controls pre-applied before issue; Engineering Management confirms new devices meet policy before granting access. Loss/theft/compromise - reported to Engineering Management immediately; remote wipe and access revocation initiated without delay. Disposal/reassignment - all sensitive data, files, and stored credentials completely erased via secure wipe; devices returned and decommissioned on separation. Technical requirements Full-disk encryption mandatory: FileVault (macOS, AES-XTS), BitLocker (Windows, AES-256), LUKS2 (Linux) Anti-malware active: XProtect/Gatekeeper (macOS), Defender (Windows), approved solution e.g. ClamAV (Linux) Timely OS/security patching; non-compliant devices may be restricted Screen lock with auto-lock enabled MFA on all system access via Microsoft Entra ID Data handling Sensitive/customer data must not be downloaded or stored on local drives; approved cloud storage only Credentials stored only in the enterprise password manager (Vaultwarden), never locally Devices not shared with anyone outside Appcircle Remote work & physical protection Devices physically secured when not in use; not left unattended in the office or in transit Encrypted Wi-Fi (WPA2+) required; public/unencrypted networks prohibited for business use BYOD - permitted only for lightweight access (e.g. communication tools), held to the same bar: MFA, screen lock, current OS, no confidential or customer data stored locally, subject to compliance review. Compliance verification - via "periodic management review and onboarding verification"; non-compliance reported to Engineering Management for follow-up. Aligned to SOC 2, ISO 27001:2022 A.8.1, GDPR Art. 32, KVKK Art. 12. Honest gaps: enforcement is policy-based and self-attested, not backed by MDM/automated compliance tooling (no Intune/Jamf/Kandji documented); remote wipe is a manual procedure with no named mechanism; detailed device configuration baselines and compliance-check procedures are maintained separately. One documented exception: datacenter Mac mini build hosts run with FileVault intentionally disabled (approved, scoped deviation - treated as infrastructure, not workstations). Sources: endpoint-device-security-policy acceptable-use-policy physical-security-policy macos-initial-setup-data-center
How are users of the system authenticated?	Two separate answers, since "users of the system" can mean platform customers or Appcircle staff. Platform (customer) authentication - Keycloak-backed: Email/password at my.appcircle.io (company email required; disposable domains blocked). Password policy: min 6 chars, at least one lowercase, one uppercase, one digit. Social login is deprecated. 2FA/TOTP - optional authenticator-app 2FA (Google/Microsoft Authenticator, FreeOTP, any SHA1 OTP app), enabled per user under My Account > Signing In. SSO - Auth0 (OIDC/SAML), Microsoft Entra ID (SAML), Okta (OIDC/SAML), OneLogin (SAML). One provider active at a time; when enabled, all org users must log in via SSO. Three independently configured modules: Dashboard, Enterprise Portal, Testing Portal. LDAP - available for the Testing Portal and Enterprise Portal, with multiple ordered providers and its own 2FA (email; SMS only on self-hosted Docker/Podman). API/CLI - org-level API Keys (default 6-month expiry, max 1 year, secret shown once, 10 per org) and user-scoped Personal Access Keys, both exchanged for tokens at auth.appcircle.io. Session control - Device Activity lists all active sessions (device, IP, expiry) with individual or bulk sign-out. Auth Activity Log - records Login/Logout/Switch Organization with email, IP, timestamp. Documented gaps: the CLI does not enforce 2FA even when it's enabled on the account, and SSO logins are not recorded in the Auth Activity Log. Internal staff authentication: MFA enforced via Microsoft Entra ID Conditional Access, with SSO via Entra ID wherever supported; no shared accounts, credentials only in the approved password manager, quarterly access reviews. Mapped to ISO 27001:2022 A.5.15-A.5.18, A.8.2-A.8.5. Sources: sso-authentication signing-in api-keys system-access-control-policy
If passwords are used, please describe password complexity requirements. (e.g., password strength, min/max length, change interval, etc.).	Two contexts, and both have documentation gaps worth being upfront about. 1. Product/platform (customer accounts) - the only documented complexity rule: Minimum length at least 6 characters At least one lowercase, one uppercase, and one numeric digit Enforced by Keycloak (non-compliant values fail the keycloak_migration service) Brute-force protection is configurable (Keycloak): protection on by default, failure factor 30, max wait 900s, quick-login checks, permanent lockout off by default. Not documented for the product: maximum length, special-character requirement, password expiry / change interval, password history / reuse restriction, and a lockout threshold for standard email/password login (lockout guidance exists only for LDAP integration). 2. Internal staff - a standalone Password Policy is referenced in three policies but does not exist as a document in the docs tree. What is documented: Strong passwords managed via the approved enterprise password manager (self-hosted Vaultwarden at pass.appcircle.io, AES-256-GCM + Argon2id, Entra ID SSO) No reuse of the same password across accounts/systems No sharing with anyone, including colleagues No plaintext storage (written or unencrypted electronic form) MFA required on all system logins via Entra ID Default passwords changed on first use Not documented for staff: minimum/maximum length, specific character-complexity rules, rotation/expiry interval, and password history/reuse-count - all of which would live in the absent Password Policy (noted as "maintained separately"). Sources: docker advanced-configuration acceptable-use-policy system-access-control-policy
Is access to confidential data based on the principle of least privilege?	Yes. Least privilege is stated as a governing principle and backed by concrete controls. System Access Control Policy (the core statements): "Least privilege: Access is granted at the minimum level required to perform a legitimate business function. No excess permissions are assigned by default." "Need-to-know: Access to sensitive data is restricted to those with a documented business need." "Separation of duties: Critical functions are divided across roles to reduce the risk of error or misuse." Individual accountability - no shared/generic accounts. Supporting enforcement: Provisioning requires formal approval before access is granted, documented via onboarding checklist capturing the access and approver. Privileged access is "restricted to the minimum number of personnel required," documented separately from standard access, and gets heightened scrutiny in reviews. Quarterly access reviews confirm each grant reflects a current legitimate business need, checking for access that should have been revoked, accumulated excess permissions, and orphaned/inactive accounts. Revocation within one business day of separation. Concrete implementations - GitHub least-privilege roles (Read/Write/Maintain) set by org owners with CODEOWNERS; GCP access via Entra ID group membership; password manager collections with a separate /Privileged collection restricted to team leads; log access restricted need-to-know; production access not inherited from a dev/test role but provisioned explicitly. Acceptable Use Policy repeats it for data sharing: "share information, documents, and system access only where there is a legitimate business need." Product side - customer orgs get module-based RBAC with read/write roles per user. Sources: system-access-control-policy acceptable-use-policy github
How often is user access reviewed? How often for privilege / administrative users?	Quarterly for all users. The System Access Control Policy states: "Access to all systems is reviewed at least quarterly to confirm that each access grant reflects a current and legitimate business need." Each review specifically checks for: Accounts that should have been revoked (e.g. after role change or departure) Excessive permissions accumulated over time Orphaned or inactive accounts Privileged/administrative users - no separate cadence. The policy says privileged access is "restricted to the minimum number of personnel required," documented separately from standard user access, and "subject to heightened scrutiny during periodic reviews." Being precise: that's greater depth of scrutiny within the same quarterly cycle, not a more frequent review interval. No distinct/more frequent review cadence for privileged accounts is documented. Related cadences for context: access revoked within one business day of separation; the policy itself reviewed at least annually. Caveat: the policy explicitly notes that detailed procedures - including "review cadences" and "privileged access controls" - are "maintained separately and may be shared under appropriate agreements," so a stricter internal cadence for admins may exist outside these docs. I also found no records evidencing completed access reviews (no sign-off artifacts) in the documentation. Source: system-access-control-policy
Do developers have access to production systems?	Not by default. The SDLC Policy is explicit: "Development, testing, and production environments are logically separated. Access to production is not granted by default as a consequence of a development or testing role; it is provisioned explicitly based on documented operational need, in accordance with the System Access Control Policy." So developer access to production is possible but must be separately justified, approved, and documented - it isn't inherited from being a developer. Where such access exists, it's gated: Bastion-only - access to VMs/containers runs through the SSO-authenticated Apache Guacamole gateway (no local SSH client or VPN), with every session recorded (90-day minimum retention) and VM passwords injected from OpenBao rather than handled by operators. Role-scoped connection groups - Guacamole splits access into sysadmin (infra/ops) and appcircle (developers) groups, gated by SSO group membership. Privileged access is restricted to the minimum number of personnel required, documented separately from standard access, and gets heightened scrutiny in the quarterly access reviews. Production changes require human approval from an authorized environment owner regardless - no unapproved automated updates. Production data is prohibited in dev/test by default, so the data flow is restricted in both directions. Honest caveat: the policy sets the rule, but the actual roster of who holds production access, and the specific privileged-access controls, are explicitly "maintained separately" and not in the published docs - so I can't evidence from documentation which developers (if any) currently have it. Sources: sdlc-policy system-access-control-policy guacamole
Is data encrypted while being processed, transmitted or stored? Please specify.	Encryption (transit / at rest / in use) In transit: TLS minimum 1.2 between all services and between services and end users; AES-256 for GCP infrastructure and the platform; unencrypted protocols not permitted for sensitive data; WPA2+ Wi-Fi required for staff. At rest: GCP-managed AES-256 on all production data stores and databases by default; databases with non-public data require encryption at rest; endpoint full-disk encryption (FileVault AES-XTS / BitLocker AES-256 / LUKS2). In use / being processed: NOT documented. No confidential computing, memory encryption, TEE/enclave, or homomorphic encryption anywhere. The closest is a secure-coding rule that secrets be held in memory as briefly as possible and explicitly cleared - a coding practice, not encryption-in-use. Sources: network-security-policy asset-management-and-data-classification-policy endpoint-device-security-policy best-practices
Does a standardized process exist for managing encryption keys? Explain.	Key management Policy-level yes, procedure-level partial. Keys are managed with controls for "secure generation, limited access, storage, rotation, and destruction," covering Appcircle-managed and GCP KMS keys, with sub-processors held to equivalent standards. Concretely: GCP KMS auto-unseal for Vault/OpenBao; OpenBao as the secrets backend (secrets delivered at runtime, never committed to source); Shamir 3-of-2 unseal on one instance; AppRole auth with path-scoped policies and short token TTLs; GCP IAM bound to the specific KMS key (least privilege); cryptographic erasure per NIST SP 800-88; encryption keys classified as Restricted data. Gaps: no key rotation cadence documented anywhere; no standalone Encryption Policy or Key Management Policy exists (both referenced by name only). What exists is scattered across ops runbooks, not a consolidated procedure. Sources: network-security-policy openbao vault-openbao-migration data-retention-and-disposal-policy 0007-vault-license-risk-and-alternatives
Is user activity to data logged?	Yes. Required logging covers data access and modification (access to sensitive data stores incl. personal data, bulk operations, schema changes, deletions), authentication/session events, authorization/privilege changes, administrative actions, infrastructure/deployment activity, and secret/key access. Each entry carries timestamp (UTC), event type, source system, actor identity, action, outcome, source IP. Product side: an Auth Activity Log records Login/Logout/Switch Organization per user (SSO logins are not captured there). Sources: logging-and-monitoring-policy auth-activity-log
Please describe activing logging and alerting capabilities.	Logging and alerting capabilities Logs forwarded to a centralized platform, collection automated, encrypted in transit, protected against unauthorized modification/deletion with integrity/change-detection; access need-to-know; admins cannot erase logs of their own activity; logging-config changes go through change management. Tooling: SigNoz + ClickHouse for the runner/agent fleet, a separate Grafana+Loki stack, and GCP monitoring/alerting + uptime checks (the tooling actually shown firing in real incidents). Alerting covers security anomalies (unusual auth patterns, unauthorized access attempts, privilege escalation, IOCs), availability/performance, infrastructure health, and critical security control failures; critical alerts route to on-call, rules tuned periodically. Sources: logging-and-monitoring-policy 0019-observability-visualization-backend-signoz 0004-ir-2026-0407-testerweb-waf-rate-limiting
Are system security events being centrally monitored? Does this occur on a 24x7 basis?	Centrally monitored: yes (centralized log platform + alerting to on-call). 24x7: not documented as such. An on-call rotation with S1-S3 response targets exists, implying round-the-clock alert response, but no document states 24x7 security monitoring coverage, and there is no SOC and no IDS/IPS deployed. Honest flags: every concrete monitoring event evidenced in incident reports was an availability/performance signal rather than security-anomaly detection; IR-0002 records detection relying entirely on customer reports for ~6 hours; and the log-review cadence and reviewer are not documented (deferred to unpublished internal standards). Sources: logging-and-monitoring-policy culture 0002-ir-2026-06-09-cloud-runner-network-instability network-security-policy
Is a formal process implemented to deploy software patches in a timely manner to protect against security vulnerabilities?	Yes at the SLA level. The Vulnerability Management Policy sets severity-based remediation timeframes across all Appcircle-operated systems, services, infrastructure, and third-party dependencies: Urgent 1 day, Critical 3 days, High 30 days, Medium 90 days, Low best-effort. Endpoints must run supported OS versions with patches "applied in a timely manner." Gap: no general OS/endpoint patch cadence (e.g. "within X days of release") is documented, and no centralized patch-deployment tooling for internal Linux VMs or endpoints. Sources: vulnerability-management-policy endpoint-device-security-policy
Is this process automated or manual? Explain process and schedule.	Mixed, by asset class: Dependencies: automated - Dependabot alerts (confirmed in use, e.g. ac-service-mcp), remediated by bumping pins and verifying with pip-audit. Container images: automated Trivy CVE scan on builds, archived as Jenkins artifacts - but gated by a when conditional and observed skipped on some release/* branches, so not universally enforced. Backend services rebuild from a shared chiseled distroless base on every branch push. Self-hosted Appcircle Server (customer): automatable via auto-update.sh on crontab, default 3:00 AM every Saturday; minor/patch releases only; unsupported with proxy/DMZ configs. macOS build hosts: deliberately not auto-patched - Software Update is disabled by design to protect the build toolchain; patching is a manual runbook re-run after each macOS update. Endpoints: self-attested, verified via "periodic management review" - no MDM-enforced update policy. Internal VMs/LXC: no patch cadence or automated patching tool documented (gap). Sources: backend-service-release auto-updating macos-host-upgrade 0007-mcp-server-v2-tool-expansion
Are there detective and preventive controls to protect against insecure and malicious software?	Preventive: endpoint anti-malware (XProtect/Gatekeeper on macOS, Defender on Windows, ClamAV-type on Linux); macOS host hardening script (firewall + stealth mode, sharing services disabled, telemetry blocked); ephemeral build VMs re-created per build (limits persistence); chiseled/distroless container base images; mandatory peer code review; secure-coding standards with strict host allowlisting (SSRF) and HTTPS-only with redirects disabled; WAF + Cloudflare DDoS + default-deny firewall/VPC segmentation; SSH/VM hardening. Detective: SAST program with dated scan reports and triaged findings; Trivy image scanning; Dependabot dependency alerts; third-party vulnerability scanning + annual penetration testing; centralized logging/monitoring that alerts on failures of critical security controls (incl. anti-malware and IDS/IPS categories) and on IOCs/unauthorized access attempts. Gaps: no centrally managed EDR/AV console (no CrowdStrike/SentinelOne/Intune-managed Defender) - anti-malware relies on built-in tools plus employee compliance; no application allowlisting (AppLocker/WDAC); on macOS build hosts the hardening script only reports SIP/FileVault/Gatekeeper status rather than force-enabling them. [4:50 PM]Sources: endpoint-device-security-policy sast-index best-practices macos-host-hardening
Do you have a Threat and Vulnerability Management Policy and Procedure?	Yes for vulnerability management: a formal Vulnerability Management Policy (effective 2026-02-05, owned by Engineering Management) covering scope, identification methods (secure-dev training, peer review, third-party scanning, annual pentest), severity classification, remediation SLAs, tracking to resolution, and exceptions. Honest gap on the "threat" half: there is no dedicated threat-intelligence policy or procedure - ISO 27001 A.5.7 (Threat intelligence) is cited for alignment but not operationalized, and no CVE-feed/vendor-advisory monitoring process is documented. Detailed procedures (tools, workflows) are maintained separately. Sources: vulnerability-management-policy risk-assessment-policy
Does your TVM Policy Contain Guidelines on acceptable response time to critical vulnerabilities? If so, how long can a critical vulnerability be open before risk mitigation or acceptance?	Yes, explicit. "Vulnerabilities are prioritised and remediated according to their severity rating": Urgent: 1 day Critical: 3 days High: 30 days Medium: 90 days Low: best effort (tracked for awareness) So a Critical vulnerability may remain open at most 3 days before remediation - or before formal risk acceptance, which requires documented justification, scope, duration, and compensating controls, approved by the policy owner (Engineering Management) or an authorized delegate and reviewed before expiry. All vulnerabilities are logged and tracked to resolution. Sources: vulnerability-management-policy risk-assessment-policy
Do you perform annual penetration testing?	Yes. The Vulnerability Management Policy states independent penetration testing is conducted at least annually by a qualified third party, "combining automated scanning with human-led exploitation techniques" to catch what automated tools miss. It's one of four documented vulnerability-identification methods alongside secure-dev training, peer code review, and third-party scanning. Findings feed the same severity-based remediation SLAs (Urgent 1d / Critical 3d / High 30d / Medium 90d). Honest note: I found no published pentest report or dated engagement record in the docs - only the policy commitment. Source: vulnerability-management-policy
Is there a formal Software Development Life Cycle (SDLC) process?	Yes. A formal SDLC Policy (effective 2026-02-05, owned by Engineering Management) defines six phases: need identification -> requirements (with a security assessment) -> system design (functional, security, scalability) -> build and test (incl. security-vulnerability coverage) -> evaluation (independent testing) -> deployment (per the Change Management Policy, after all required checks). Security controls run throughout: separation of dev/test/prod, mandatory peer review, secure coding standards, OWASP compliance, human approval for production changes, removal of test credentials before release, secure error handling. Aligned to SOC 2, ISO 27001:2022 A.8.25-A.8.31, GDPR Art. 25, KVKK Art. 12. Source: sdlc-policy
Is a Secure Code Review performed regularly?	Yes, on every change. "All code changes are reviewed by at least one person other than the author, with reviewers expected to be knowledgeable in secure coding practices," and the Vulnerability Management Policy confirms peer review "includes assessment of code quality and potential security vulnerabilities before approval." Structurally enforced via a CODEOWNERS file in every repo naming who is accountable for review. Complemented by a SAST program whose findings are triaged against the secure-coding standard's numbered rules. Honest gap: SAST is not yet a blocking CI gate - ADR-0015 lists "evaluate SonarQube and OWASP integration inside the existing Jenkins pipelines" as an open follow-up, so current evidence is periodic scans plus manual review. Sources: sdlc-policy sast-index 0015-retain-github-linear-jenkins-stack
Are web applications configured to follow best practices or security guidelines e.g., OWASP?	Yes, mandated. The SDLC Policy states: "All software deployed on Appcircle's infrastructure must prevent security issues addressed by OWASP top 10 and SANS standards," with annual security training including OWASP Top 10 awareness for anyone writing/supporting customer-facing or internet-exposed code. Backed by a concrete engineering best-practices standard covering SSRF prevention (host allowlisting, HTTPS-only, redirects disabled, centralized validation), secret handling, debug-code isolation (#if DEBUG, no debug endpoints in prod), CSPRNG for security-sensitive randomness, and TLS/certificate validation rules - with C# examples. Runtime protections include a WAF, rate limiting, and default-deny firewalling. Sources: sdlc-policy best-practices
Is data input into applications validated?	Yes, with a documented standard. The engineering security best-practices doc has a dedicated API validation section requiring validation at the boundary using FluentValidation rather than scattered [Required] attributes, and nullable types for genuinely optional fields. It also mandates strict allowlist/regex validation for any user-supplied URL, host, or path (SSRF prevention) via centralized validation helpers. SAST findings are cross-referenced back to these numbered rules (e.g. [API Validation, 1-2]), showing the standard is actively enforced in triage. Sources: best-practices sast-index
Before code is promoted to production is it scanned for vulnerabilities	Partially, and honestly not as a hard gate. Backend service builds run a Trivy scan (pulls the freshly pushed image, downloads the CVE DB, scans for OS and language-level CVEs, results archived as Jenkins artifacts) - but the stage is gated by a when conditional and has been observed skipped on some release/* builds, so scanning is not guaranteed on every promotion path. SAST runs as a periodic program with dated reports and triaged findings, not as a blocking pipeline gate; ADR-0015 still lists "evaluate SonarQube and OWASP integration inside the existing Jenkins pipelines" as an open follow-up. Dependabot provides dependency alerting (confirmed on at least one repo). So: automated scanning exists and runs pre-production in the common path, but there is no documented blocking quality gate that prevents promotion on findings. Sources: backend-service-release sast-index 0015-retain-github-linear-jenkins-stack
Before code is promoted to production is it peer reviewed	Yes, mandatory. "All code changes are reviewed by at least one person other than the author, with reviewers expected to be knowledgeable in secure coding practices" (SDLC Policy), and the Change Management Policy states "peer review and approval of code changes are systematically enforced." Structurally backed by a CODEOWNERS file in every repo naming the accountable reviewer. Promotion runs dev -> test (impact assessment, integration testing, review, approval) -> production, and production changes additionally require human approval from an authorized environment owner. Sources: sdlc-policy change-management-policy github
Where will data be stored and process? (Company managed data center, Cloud or Data Center provider, combination of both)	Primarily cloud provider (Google Cloud Platform) - the Physical Security Policy states production infrastructure is hosted on GCP and "production systems and customer data reside entirely on cloud infrastructure managed by Google - no sensitive production data is stored on-premises." Honest caveat: it is in practice a combination, because other internal docs describe Appcircle-operated hardware not reconciled in that policy: macOS build runners in a Teknotel colocation datacenter (Telehouse Istanbul), an OVHcloud Proxmox cluster, and a small on-prem lab (5-6 physical hosts, ADR-0004). Those carry build infrastructure rather than customer production data as documented, but the "entirely on GCP" framing is broader than the full estate. Separately, self-hosted customers run entirely on their own infrastructure, outside Appcircle's scope. Sources: physical-security-policy 0004-virtualization-platform ovh-infrastructure
Describe physical entry and environmental controls employed that pertain to areas (i.e., data centers) that host information.	Physical and environmental controls for GCP data centres (including access controls, surveillance, environmental protection, and media handling) are governed and operated by Google... evidenced by GCP's SOC 2 Type II report." Appcircle reviews those certifications under its vendor management program.?Appcircle-operated locations: the Istanbul office has access restricted to authorized personnel, visitor acknowledgement/escort at reception, clean desk, locked storage for sensitive documents, and no unattended devices. For the Teknotel colo and on-prem lab, no physical entry or environmental controls (badges, CCTV, alarms, power/cooling/fire monitoring) are documented - only a remote-hands ticketing procedure and network-link monitoring. That's a genuine documentation gap.?Sources: physical-security-policy teknotel-ticketing-guide
Is all data center access monitored and logged?	For GCP: yes, by Google - surveillance and access controls are part of the delegated physical control set evidenced by GCP's SOC 2 Type II report; Appcircle has no direct physical access to those facilities. For Appcircle-operated facilities: not documented. No CCTV, badge logs, visitor logs, or alarm monitoring is described for the office, the Teknotel colocation cabinet, or the on-prem lab. Physical access there happens via Teknotel remote-hands tickets (which create a ticket trail, but that isn't an access-monitoring control). What is logged is logical access to infrastructure: all VM/container access goes through the SSO-authenticated Guacamole bastion with every session recorded (90-day minimum retention), plus policy-required logging of administrative actions, privilege changes, and secret/key access, with logs tamper-protected and non-erasable by their own actor. Sources: physical-security-policy guacamole logging-and-monitoring-policy
Are visitor logs maintained for at least 90 days?	No. The Physical Security Policy requires that "visitor access requires acknowledgement at reception or equivalent escort controls," but no visitor log system, and no retention period for one, is documented for the Istanbul office. For GCP data centers, visitor logging is part of Google's delegated physical controls (evidenced by their SOC 2 Type II report), but Appcircle does not define the retention. The only documented 90-day retention in Appcircle's own environment is for Guacamole privileged session recordings (logical, not physical, access). Sources: physical-security-policy guacamole
Do all systems use uninterruptible power supply (UPS) systems?	Not documented by Appcircle. For production, power/environmental protection is delegated to Google ("environmental protection" is explicitly named among GCP's operated controls). For the Teknotel colocation cabinet, the docs only reference PDU/power cabling checks via remote-hands tickets, and the Mac mini setup guide includes a "power recovery tested" checklist item (device auto-recovers after a power interruption) - a device-resilience test, not evidence of a UPS. No UPS is documented for the office or on-prem lab. Sources: physical-security-policy teknotel-ticketing-guide macos-initial-setup-data-center
Does the data center use fire protection/suppression systems?	Not documented by Appcircle; delegated for production. GCP's "environmental protection" controls cover this for production infrastructure, evidenced by Google's SOC 2 Type II report. No fire detection or suppression system is documented for the Teknotel colocation space, the on-prem lab, or the office - those facilities' environmental controls would be the colocation provider's responsibility, but Appcircle's docs don't record or evidence them. Source: physical-security-policy
Does the data center use redundant public utility connections?	Not documented at facility level. What is documented is infrastructure-level redundancy: production runs multi-region on GCP with cross-region backup replication, and the DR Plan targets failover to a secondary GCP project in a different region (RTO <16h, RPO <24h). Facility-level utility redundancy (dual power feeds, diverse network carriers) is part of Google's delegated environmental controls for GCP; for Teknotel/on-prem it is not documented. Sources: physical-security-policy disaster-recovery-plan
Do you conduct independent third-party audits to ensure compliance to regulatory requirements and your own security policies?	Partially. What is documented: Annual third-party penetration testing by a qualified independent firm (combining automated scanning with human-led exploitation). Third-party vulnerability scanning of systems, dependencies, and infrastructure. Vendor accreditation reviews - Appcircle reviews its vendors' SOC 2 Type II / ISO 27001 attestations under the Vendor Management Policy, and relies on GCP's SOC 2 Type II report as evidence for delegated infrastructure controls. Policies are reviewed at least annually and mapped to SOC 2, ISO 27001:2022, GDPR, KVKK. Honest gap: the docs describe Appcircle's controls as designed to support/align with SOC 2 and ISO 27001 - they do not state that Appcircle itself currently holds a SOC 2 attestation or ISO 27001 certification, and I found no audit report, auditor name, or attestation record in the documentation. The only third-party attestation actually cited as evidence is GCP's, not Appcircle's. Internal compliance verification is described as periodic control assessments and evidence collection, not as an external audit. Sources: vulnerability-management-policy vendor-management-policy information-security-policy
If so, how often are the audits conducted? What are the applicable regulatory requirements?	Documented cadences: penetration testing at least annually (independent third party); policy review at least annually or on significant business/technology/regulatory change; risk assessment at least annually plus ad hoc on new systems/major changes/post-incident; access reviews quarterly; DR testing quarterly tabletop / semi-annual component restore / annual full simulation. Applicable regulatory requirements cited across the policies: SOC 2 (Trust Services Criteria), ISO/IEC 27001:2022 (Annex A controls per policy), ISO/IEC 27701:2019 (privacy management, in the disposal policy), GDPR (Arts. 5, 25, 28, 32, 33/34, 35), KVKK (Law 6698, Art. 12), and NIST SP 800-88 for media sanitization. Honest note: no external audit engagement, auditor, or attestation report is recorded in the docs - the only third-party attestation cited is GCP's SOC 2 Type II. Sources: vulnerability-management-policy information-security-policy risk-assessment-policy disaster-recovery-plan
Is the company compliant to applicable regulations pertaining to the data being managed such as SOX, PCI DSS, GLBA, HIPAA? Explain those that apply and whether or not your organization is compliant.	None of these four are referenced anywhere in Appcircle's documentation. No policy claims SOX, PCI DSS, GLBA, or HIPAA compliance, and no controls are mapped to them. That is consistent with the business: Appcircle is a mobile CI/CD and app-distribution platform, not a payment processor, financial institution, or healthcare provider. The one adjacent control is in the Logging and Monitoring Policy, which forbids "unmasked payment card data" in logs - a hygiene rule, not a PCI DSS compliance claim. The frameworks that do apply are SOC 2, ISO 27001:2022 / 27701:2019, GDPR, and KVKK - and there too, the docs describe controls as aligned to them rather than asserting a current attestation or certification for Appcircle itself. Sources: information-security-policy logging-and-monitoring-policy
Do you have a record retention policy and procedures in place to support it?	Yes - a Data Retention and Disposal Policy (effective 2026-02-05, owned by Engineering Management). It is classification-driven: retention periods and disposal methods determined by data classification (Restricted/Confidential/Internal/Public). Backup data is disposed in alignment with source-data retention at the next scheduled backup rotation. Legal holds override normal retention until explicitly lifted, documented with scope, reason, and affected data categories. Disposal activities are logged and auditable; Engineering/Platform/Operations executes deletions and maintains disposal logs. Product-side support: Enterprise organizations get configurable per-module retention/auto-deletion rules (Build, Testing Distribution, Publish, Enterprise App Store) from 1 week to "never delete"; Starter orgs have a fixed monthly auto-purge. Caveat: the detailed retention schedule with specific periods is maintained as a separate internal document, not published - so I cannot state actual retention durations from the docs. Sources: data-retention-and-disposal-policy retention-period
What is your data disposal procedure?	Method by medium: Cloud - cloud-native deletion mechanisms and cryptographic erasure per NIST SP 800-88 On-premise - secure overwrite, cryptographic erasure, or physical destruction as appropriate Personnel work devices - secure wipe or factory reset before reassignment, return, or disposal Physical media - cross-cut shredding or certified destruction through vetted vendors SaaS / third-party tools - deletion via built-in capability or API, verified against vendor disposal practices; vendor contracts require data return/deletion on termination Backups - disposed in alignment with source retention at the next backup rotation Stronger methods apply to higher-sensitivity data. Disposal is logged and auditable. Self-hosted deployments are excluded - data lifecycle there is the customer's responsibility. Source: data-retention-and-disposal-policy
Can individual records containing PII/PHI be deleted?	Yes. The Data Retention and Disposal Policy documents supported data-subject rights: right to erasure ("data subjects may request deletion of their personal data, subject to legal retention obligations"), right to restriction of processing, and data portability - "fulfilled within the timeframes required by applicable law," with a Data Protection Contact role handling requests and advising on privacy compliance. Where a legal obligation requires continued retention, the data subject is informed of the specific legal basis. Product mechanisms: account owners can delete their account (staged - 24h deactivation, then permanent deletion, with a deletion confirmation on request); Enterprise orgs get per-module retention/auto-deletion; an Artifacts Report logs deletions including a "Physically Delete" flag showing whether the artifact was permanently removed from storage. Note on PHI specifically: Appcircle does not document HIPAA applicability or any PHI handling - the erasure capability above is framed under GDPR/KVKK personal data, not PHI. Sources: data-retention-and-disposal-policy delete-account retention-period
Will data be shared with your organization's third parties or contracted out?	Yes, with sub-processors under a formal vendor program. Named third parties across the policies: Google Cloud Platform (production infrastructure), Microsoft 365 / Entra ID (identity, email), GitHub (source code), Cloudflare (DNS, DDoS mitigation), plus Bitwarden/Vaultwarden and Linear as corporate systems. Each vendor requires a security risk assessment, accreditation review (SOC 2 Type II / ISO 27001), management approval before onboarding, and a named accountable Appcircle owner in a vendor register. Contracts must cover data protection/confidentiality, breach notification aligned to Appcircle's IR process, sub-processor restrictions and disclosure, and data return/deletion on termination. Gap: there is no published, customer-facing sub-processor list - the vendor register is internal-only, shared under agreement. Sources: vendor-management-policy network-security-policy
Do applications containing personal data have an inactivity timeout? How long?	Session termination capability exists, but no timeout duration is documented
Will data stored/processed/transferred by your organization cross national borders?	Depends on the hosting model: SaaS / Single Tenant - hosted on Appcircle's GCP (internal DR tooling references europe-west1), so data may be processed outside the customer's country. Appcircle is Türkiye-based with US incorporation, and vendors (GCP, Microsoft, GitHub, Cloudflare) are multinational - so yes, cross-border transfer occurs. Self-Hosted / Private Cloud - runs entirely in the customer's environment: "full data sovereignty," customer controls geography.
Do you have a documented enterprise Privacy Policy? Please share.	A published one exists: **privacy-policy** ("Appcircle Inc. Privacy Policy"), linked from the docs site footer. Important caveat to raise before sharing it: it is a generic, US-oriented website/consumer privacy notice - it covers cookies, COPPA, and opt-out, and states that users outside the US agree their information may be stored in the United States. It does not mention GDPR, KVKK, sub-processors, GCP, or data residency. Meanwhile the internal governance program repeatedly cites GDPR/KVKK obligations and references a "Data Protection Policy" that does not exist as a document in the governance folder.
Does a formal disaster recovery (DR) and business continuity (BC) plan exist?	Yes, both. A Business Continuity and Disaster Recovery Policy (governing continuity, the Emergency Response Team, and stakeholder communication) plus a detailed Disaster Recovery Plan with: RTO < 16 hours, RPO < 24 hours Per-component backup mechanisms (Cloud SQL daily, MongoDB daily via GCP Backup & DR, multi-region object replication, Artifact Registry, Vault/KMS) An 8-step ordered recovery sequence with automation scripts, cross-region failover to a secondary GCP project Documented activation criteria (incl. "security incident requiring full environment isolation and rebuild") Testing cadence: quarterly tabletop, semi-annual component restore drills, annual full DR simulation Caveats: self-hosted deployments are excluded (customer-managed DR), and one MongoDB restore script is flagged in-repo as "not tested and may have errors on first run." Sources: disaster-recovery-plan business-continuity-and-disaster-recovery-policy hosting-options
Is all data backed up and stored offsite?	For Appcircle-managed environments, production data is backed up with cross-region redundancy: PostgreSQL - GCP Cloud SQL automated backups, daily + on-demand MongoDB - GCP Backup & DR vault backups, daily Object storage - continuous multi-region replication Container images - Artifact Registry on every deployment Vault/OpenBao secrets - GCS backend with KMS auto-seal, continuous "Offsite" is satisfied via multi-region storage and cross-region backup replication (production only), with DR failover to a secondary GCP project in a different region. Important qualifiers: non-production has no automated daily backups and no multi-region/cross-region replication; self-hosted deployments are excluded entirely (customer-managed backup/DR). So "all data" is not accurate - production, yes; non-prod and self-hosted, no. Sources: disaster-recovery-plan hosting-options
What is the recovery time objective (RTO)? What is the recovery point objective (RPO)?	RTO < 16 hours - full platform restoration RPO < 24 hours - based on daily automated backups Partial (single-component) failures recover faster. Per-function RTO/RPO are also defined in a separate Business Impact Analysis referenced by the BC/DR Policy. Validated via quarterly tabletop, semi-annual component restore drills, and an annual full DR simulation. Sources: disaster-recovery-plan business-continuity-and-disaster-recovery-policy
Are procedures implemented to ensure for the secure management, handling, storage and disposal of removable computer media?	Only partially documented, and I'd flag this as a gap. Disposal is documented: physical media are disposed of by "cross-cut shredding or certified destruction through vetted vendors"; on-premise media via secure overwrite, cryptographic erasure, or physical destruction; devices securely wiped before reassignment/disposal. Storage/handling of sensitive material: physical documents with sensitive information kept in locked storage; clean desk enforced; devices not left unattended. Not documented: there is no removable-media policy - no rules on USB/external drive usage, no encryption requirement specific to removable media, no registration/tracking of removable media, and no port control or USB blocking (consistent with the absence of central MDM/DLP on endpoints). The general rule that sensitive data must not be stored on local drives and must use approved cloud storage indirectly discourages removable media, but there's no explicit control. Sources: data-retention-and-disposal-policy physical-security-policy endpoint-device-security-policy
Is confidential data encrypted on backup media?	Not explicitly documented
Do you have a Security Incident Management Program?	Yes. A formal Incident Response Plan (effective 2026-02-05, owned by Engineering Management) with a six-stage lifecycle: Preparation -> Identification and classification -> Containment -> Eradication -> Recovery -> Closure and post-incident review. Includes severity assessment (data sensitivity, scope, escalation risk, reputational impact), defined roles, ERT-governed stakeholder communication, and regulatory breach notification (GDPR Art. 33 72-hour, Art. 34, KVKK Art. 12). Backed by a real, mature incident record archive - 13 incidents (IR-0001 to IR-0013, 2025-09 to 2026-07), all resolved, each with root-cause analysis, timeline, CAPA table, data/privacy impact assessment, communication log, and sign-off. Honest gaps: the plan states IR testing occurs "at least annually," but no record of an actual IR tabletop/simulation exists; no S1/S2/S3 response-time SLA is published; and ERT membership/contact lists are maintained outside the docs. Sources: incident-response-plan index 0001-ir-2026-0224
Please describe yoru security incident procedures.	Six-stage lifecycle per the Incident Response Plan: Preparation - documented plans, defined roles, access and tooling; plans tested at least annually Identification and classification - via monitoring/alerting, internal reporting, third-party notification, or customer reports; severity assessed on data sensitivity, users/systems affected, escalation risk, reputational impact Containment - removing/restricting access to exposed data, isolating or shutting down compromised systems, temporary access/config restrictions, weighed against destroying forensic evidence; high-severity incidents proceed straight to containment Eradication - root-cause fix, malware removal, credential revocation, with documented time/date/duration, systems and data types involved, discovery timeline, and cause Recovery - full restoration plus post-recovery monitoring for recurrence or residual IOCs Closure and post-incident review - root causes identified, detection coverage assessed, improvements implemented Roles: Engineering Management (accountable, final decisions on major incidents and external comms), Engineering/Platform/Operations (leads containment/eradication/recovery), all personnel (report promptly). An Emergency Response Team handles major incidents and determines communication timing/scope/content. On-call rotation with a single Incident Commander per incident. Source: incident-response-plan
Do you have documented procedures for handling security incidents?	Yes, and evidenced in practice. Beyond the plan itself, there is a real incident archive: 13 incident reports (IR-0001 to IR-0013, Sept 2025 - July 2026), all resolved, each following a standard structure - executive summary, impact assessment, root-cause analysis, timeline, containment and resolution, Corrective & Preventive Actions (CAPA) table with owners and status, lessons learned, data & privacy impact assessment, communication log, and formal sign-off. Gaps to be transparent about: the detailed response runbooks, escalation paths, and ERT contact lists are maintained separately (not published); no record exists of an actual IR tabletop/simulation having been run; and no S1/S2/S3 response-time SLA is published. Sources: index 0001-ir-2026-0224
Do you have capability to notify of an incident within 48 hours?	Yes, comfortably within documented obligations - the regulatory bar is stricter. GDPR Art. 33 requires supervisory-authority notification "without undue delay and, where feasible, within 72 hours"; Art. 34 requires notifying affected data subjects without undue delay for high-risk breaches; KVKK Art. 12 equivalents apply. Contractual customer-notification obligations are separately honored, and vendor contracts require breach notification aligned to Appcircle's IR process. Evidence from practice: customer notification in real incidents ranged from same-hour to ~6 hours - all well inside 48 hours. Honest caveats: there is no formal customer-notification SLA (a SEV-2 notification SLA is an open CAPA item still in backlog), no pre-drafted notification templates, and no role explicitly assigned to file the regulatory notification. No IR in the archive has actually triggered a GDPR/KVKK notification, so the 72-hour process is documented but not yet exercised. [5:24 PM]Sources: incident-response-plan 0002-ir-2026-06-09-cloud-runner-network-instability
What service(s) will / does your organization provide to or Customer(s) of Eton Solutions?	A mobile DevOps / CI-CD platform for iOS and Android: Build - cloud or self-hosted CI/CD pipelines with configurable workflow steps Signing Identities - management of Apple certificates, identifiers, devices, provisioning profiles, and Android keystores; binary re-signing Testing Distribution - internal tester distribution via a Testing Portal (with its own SSO/LDAP) Publish to Stores - automated submission to App Store Connect / Google Play (and Huawei/Intune targets) Enterprise App Store - private in-house app distribution portal Code Push - over-the-air updates Self-hosted runners and self-hosted server for customers requiring on-prem execution Deployment models: SaaS (Appcircle-managed cloud), Single Tenant / Dedicated GCP (dedicated Appcircle-managed tenant), and Self-Hosted / Private Cloud (fully customer-managed, full data sovereignty). Sources: signing-identities hosting-options
Where does your organization perform / provide service(s) from for Eton Solutions? (Provide detail including City/State/Country.). Please detail in Additional information column.	Production infrastructure - Google Cloud Platform; internal DR tooling references region europe-west1 (Belgium, EU). No customer-facing region statement or per-region residency option is published. Corporate presence - a physical office in Istanbul, Türkiye, used on a limited/flexible basis; the workforce is predominantly remote, so personnel may operate from other locations (no locations list is documented). Build/runner infrastructure - macOS build hosts in a Teknotel colocation datacenter (Telehouse Istanbul, Türkiye); additional infrastructure on OVHcloud; a small on-prem lab. Legal entity - the published privacy policy is issued by "Appcircle Inc." and states that information may be stored in the United States.
Will any of the services that your organization provides to Eton Solutions, or its Customers, be provided from Offshore location(s)? (If Yes, please detail locations where services will be provided in the additional information column)	Services are delivered from: Türkiye - Istanbul office; macOS build runners in a Teknotel colocation datacenter (Telehouse Istanbul); predominantly remote Türkiye-based workforce EU - production on GCP, internal DR tooling references europe-west1 (Belgium); OVHcloud infrastructure US - the contracting entity per the published privacy policy is "Appcircle Inc.", which states information may be stored in the United States So for a US or EU customer, yes, part of delivery is from Türkiye. Flag: the docs don't publish an authoritative country list or the legal registered address, and the privacy policy's US-storage statement conflicts with the EU/Türkiye infrastructure documented internally. Confirm the definitive list with Osman/Onur before submitting. Sources: hosting-options physical-security-policy privacy-policy
Which of the following data handling tasks does your organization perform for Services or Eton Customers? (include where these tasks are accessed in the comments.) Please detail in Additional information column.	Storage - build artifacts, binaries, dSYMs, signing certificates/keystores, account and organization data; on GCP (Cloud SQL, MongoDB, object storage) Processing - CI/CD build execution on cloud runners (macOS/Linux), code signing, binary re-signing, store submission Transmission - to app stores (App Store Connect, Google Play, Huawei, Intune), to testers via Testing Distribution, webhooks to customer systems Hosting - the platform itself (SaaS / single-tenant) Backup - daily automated backups with cross-region replication Support/engineering access - only via the SSO-authenticated Guacamole bastion, session-recorded (90-day retention); production access not granted by default to dev/test roles Not performed: payment card processing, physical media handling, and (for self-hosted customers) any storage/processing at all - that runs entirely in the customer's environment Sources: hosting-options guacamole disaster-recovery-plan
Does your organization's product(s) or service(s) involve any of the following: a) Protected Health Information (PHI), b) Personally Identifiable Information (PII) or c) Payment Card Industry Data Security Standard (PCI DSS)?	PII - Yes. The platform holds personal data: user accounts (name, email), tester email addresses in Testing Distribution, auth activity logs (email + IP + timestamp), and device/session records. The Data Retention and Disposal Policy classifies "customer data, PII" as Confidential and supports data-subject erasure/restriction/portability rights under GDPR/KVKK. PHI - No. HIPAA is not referenced anywhere in the documentation, and no PHI handling is documented. (Note: a customer could build a healthcare app on the platform, but Appcircle does not process PHI as part of its service and has no documented HIPAA program or BAA.) PCI DSS - Not documented, and no PCI scope is claimed. The only card-related reference is a Logging and Monitoring Policy rule forbidding "unmasked payment card data" in logs - a hygiene control, not a PCI compliance claim. I found no documentation of how subscription billing/payment cards are handled (i.e. whether a third-party processor keeps Appcircle out of PCI scope). Confirm with Onur/finance before answering this line rather than asserting either way. Sources: data-retention-and-disposal-policy logging-and-monitoring-policy
Which of the Regulations and/or Standards does your organization comply with? Please detail the regulations and/or standands in the Additional Information column	Cited consistently in every policy's "Regulatory alignment" section: SOC 2 (Trust Services Criteria) ISO/IEC 27001:2022 (Annex A controls mapped per policy) ISO/IEC 27701:2019 (privacy management, in the disposal policy) GDPR (EU 2016/679 - Arts. 5, 25, 28, 32, 33/34, 35) KVKK (Türkiye Law No. 6698, Art. 12) NIST SP 800-88 (media sanitization/secure erasure) Not applicable / not referenced: SOX, PCI DSS, GLBA, HIPAA, COBIT, HITRUST, NIST CSF/800-53. Source: information-security-policy
Does your organization certified (or) assessed for ISO 27001, ISO 27701, GDPR, PCI DSS, SOX, SOC 2,etc. Please provide the details in the Additional Information column	ISO 27001, GDPR, SOC 2 Type 2 (documents can be provided upon request)
If yes, Share the ISO 27001 certificate, scope of the audit, audit report, etc.	Can be sent upon request
If yes, Share the ISO 27701 certificate, scope of the audit, audit report, etc.	N/A
If yes, Share the SOC 2 report.	Can be sent upon request
Does your organization have a signed and executed Master Services Agreement (MSA) with Eton ? (If Yes, please include the date of execution and the contract end date in comments and attach the document.)	Depends on the company
Does your organization adhere to the privacy laws and regulations in the counties covered in the contract? e.g., Canada -Personal Information Protection and Electronic Documents Act (PIPEDA) European Union - GDPR Switzerland - FADP 2020 United Kingdom - Data Protection Act 2018 USA - California Consumer Privacy Act (CCPA), California Privacy Rights Act (CPRA) New Zealand - Privacy Act 2020 and the Privacy Principles etc.. If Yes, Please include the applicable privacy regulations in the in the additional information column)	GDPR (EU 2016/679) and KVKK (Turkey, Law 6698)
Does your organization have a Data Processing Agreement (DPA) with Eton Solutions?	Depends on the company
Is there a named official/officer within your organization that is directly responsible for the oversight of Information Security? (If Yes, please provide Name/Title.)	Policy owner is a role: "Engineering Management (Security Program Owner)
Is there a named official/officer within your organization that is directly responsible for Information Privacy oversight? (If Yes, please provide Name/Title.)	No named DPO
Is there a named Compliance Officer within you organization? (If Yes, please provide Name/Title.)	All governance policies list the owner as a role: "Engineering Management (Security Program Owner)".
Does your organization communicate Policies and Procedures to all of your staff including employees and subcontractors?	The Acceptable Use Policy requires that "all employees, contractors, and other applicable third parties with access to Appcircle systems and data must read, acknowledge, and accept" it, plus mandatory security awareness training. Same scope in the Information Security Policy and System Access Control Policy. Onboarding requires SOC 2 / KVKK / GDPR awareness training and documented policy review sign-off.
Has your organization experienced any security incidents that resulted in a breach? (If Yes, please provide more information in comments.)	No
Does your organization have Cyber Security Insurance to mitigate against loss in event of an incident or breach? (If Yes, include Certificate of Insurance (COI).)	Not documented
Demonstrate the HR Security Policy.	Not documented
Does your company policy require that a criminal background check be performed as part of Human Resources hiring practices?	Background check (if required for the role)
Demonstrate the background verification process deployed by your organization. Is it done through phone calls, emails, or physical visits, or, some other means? Describe the whole process.	N/A
Is the background verification is conducted in-house or is it performed by your vendor?	N/A
If performed by the 3rd party, who is the background verification vendor? Please share (in comments) what is being covered while the BGV checks are conducted.	N/A
How are you assuring the background verification (BGV) checks and validation is conducted properly by your vendor against the selected candidate, if any?	N/A
Are the BGV documents performed for the contractors are digitally signed before sharing the report with the ETON Solutions? Please share any document digitally signed with your digital signature and share it as an attachment for verification.	N/A
Does your company require as part of standard contracting practices that all vendors agree to performing criminal background checks prior to granting their constituents access to any systems or data that is in-scope for this engagement?	N/A
What regulatory and compliance requirements apply to your organization regarding the detection and management of vulnerabilities in the service (e.g., data breach notification)?	Vulnerability Management Policy cites SOC 2 (CC/Risk Management), ISO/IEC 27001:2022 A.8.8, GDPR Art. 32, KVKK Art. 12. Incident Response Plan cites SOC 2, ISO 27001 A.5.24-A.5.28, GDPR Art. 33/34, KVKK Art. 12. Breach notification: supervisory authority within 72 hours (Art. 33), data subjects without undue delay where high risk (Art. 34), plus contractual customer notification obligations.
Do you plan to perform independent vulnerability testing of any system components (i.e. by your organization or a third-party, where permitted)? If third-party testers are used, are they certified?	yes: "Independent penetration testing is conducted at least annually by a qualified third party," combining automated scanning with human-led exploitation, plus third-party scanning tools for systems, dependencies and infrastructure. Remediation SLAs: Urgent 1 day, Critical 3 days, High 30 days, Medium 90 days, Low best effort. No tester certification requirement is documented (no CREST/OSCP/CEH)
Is all network transfer of Customer Restricted Data encrypted when traversing the service provider's network and the Customer network or non-Customer networks?	yes. Network Security Policy: all data between services and between services and end users encrypted with TLS 1.2 minimum; unencrypted protocols not permitted for sensitive data; AES-256 on GCP infra; at rest AES-256 via GCP-managed encryption; full-disk encryption on endpoints; VPC segmentation with prod separated from dev/test.
Does the service provider have a documented process for reporting security incidents involving systems used to store/access/modify hosted Customer data to the Customer Unit contact or, if appropriate, law enforcement?	yes, documented in the Incident Response Plan: an Emergency Response Team decides timing, scope and content of stakeholder communications, weighing affected-party needs, regulatory timelines and internal-before-public sequencing; all communication decisions are recorded.
What process does the service provider have in place to identify security breaches on vendor managed systems (e.g. file integrity checks)?	Logging and Monitoring Policy: centralized log aggregation across prod/staging/CI-CD, encrypted in transit; alerting on auth anomalies, unauthorized access attempts, privilege escalation and indicators of compromise; monitoring of critical security-control failures including IDS/IPS, anti-malware and audit logging; integrity monitoring/change-detection applied to log data; scheduled log review. Anti-malware per-OS in the Endpoint Device Security Policy.
In the case of a security breach or unexpected exposure of Customer Restricted Data, what are the service provider's incident response procedures?	Fully documented in the Incident Response Plan. Categories: data breach / security breach / service outage. Six phases: Preparation, Identification and classification, Containment, Eradication, Recovery, Closure with post-incident review. Severity is assessed on data sensitivity, users/systems affected, ongoing escalation risk and reputational impact (no SEV1/2/3 scale is named); high-severity incidents may go straight to containment. Containment decisions weigh forensic-evidence preservation. Eradication records time/date/duration, data types and systems, discovery timeline, cause. Roles: Engineering Management accountable for major-incident and external-comms decisions, Engineering/Platform/Operations execute, all personnel report promptly, with an Emergency Response Team owning communications. Notification per GDPR Art. 33 (72h) / Art. 34 and KVKK Art. 12, plus contractual customer obligations. Detailed runbooks and contact lists are internal, shareable under agreement.
Is there an annual schedule of planned Disaster Recovery and other Business Resiliency exercises and tests?	Yes. The Disaster Recovery Plan defines a fixed schedule: tabletop exercise quarterly, component restore drill (DB/storage restored to an isolated project) semi-annually, integrated full-stack DR simulation annually. Results are documented and feed back into the plan. Targets: RTO < 16 hours, RPO < 24 hours. Backups: Cloud SQL daily + on-demand, MongoDB daily via GCP Backup & DR, object storage multi-region replication, Vault continuous. BCP and the IR plan are each tested at least annually (walkthroughs, tabletops, simulations, third-party-led assessments).
Will the Vendor require physical access after-hours?	No, production runs entirely on GCP; there is no Appcircle presence at customer sites
Are End User Devices (Desktops, Laptops, Tablets, Smartphones) used for transmitting, processing or storing and Customers Data?	Customer and sensitive data must not be stored on local drives - approved cloud storage only, and BYOD devices must meet the same requirements with no local customer data. So devices transmit/process, they do not store customer data.
Does your organization regularly (preferably once a year) Information security and provide data protection awareness training for all its staff in relation to personal data and data protection in order to ensure its business demonstrate support for data protection legislation and promote a positive culture of data protection compliance across the business?	All personnel must complete mandatory information security awareness training, and onboarding requires distinct GDPR and KVKK data-protection awareness training plus SOC 2 security training, with completion documented (date and confirmation).
Are Phishing attacks/mails controlled in your organization? If so please, provide explanation.	Yes, controlled, across four layers: Email platform controls - Network Security Policy: the Microsoft 365 email environment is configured with SPF, DKIM and DMARC to reduce spoofing, phishing and domain impersonation. Microsoft Purview DLP restricts transmission of sensitive data over email and collaboration services. Identity controls - MFA enforced on all system access via Microsoft Entra ID Conditional Access, SSO wherever supported (System Access Control Policy), credentials kept in a password manager (Vaultwarden), which limits the value of harvested credentials. People controls - Acceptable Use Policy: "phishing attempts... must be reported to Engineering Management and must not be forwarded to other employees," plus mandatory security awareness training. The culture handbook adds "Be alert to phishing - verify unexpected requests for credentials, money, or data through a second channel before acting" and a blame-free rule so a phishing click gets reported early rather than hidden. Response - a successful phish is handled under the Incident Response Plan (eradication explicitly includes revoking compromised credentials), with immediate access revocation when credential compromise is suspected, and remote wipe + revocation for a compromised device.

Evidence Requests

Question	Answer
Anti-Virus / Anti-Malware Evidence	Task to Platform team
Architecture Diagram	Available diagram: self-hosted
Audit Logs / Alerts / Monitoring Evidence	Task to Platform team
Data Flow Diagram	Task to Platform team
Data Hosting Environment	Model / responsibility split - Hosting Options: SaaS multi-tenant (Appcircle-operated, logical tenant isolation), Single Tenant (customer-dedicated in Appcircle's GCP, Appcircle-operated, independent release cadence), Self-Hosted (customer environment, customer-owned operations). Includes a data residency/sovereignty row: Appcircle cloud / dedicated tenant in Appcircle GCP / full customer control. Provider and physical controls - Physical Security Policy: production infrastructure hosted on Google Cloud Platform; data-centre access, surveillance, environmental protection and media handling are operated by Google and evidenced by GCP's SOC 2 Type II. No production data on-premises; the Istanbul office is limited-use with a remote-first workforce. Data stores and resilience - Disaster Recovery Plan: Cloud SQL PostgreSQL, MongoDB, GCS object storage with multi-region replication in prod, Artifact Registry, Vault on a GCS backend with KMS auto-seal. DR is cross-project migration within GCP to a secondary project in a different region. RTO < 16h, RPO < 24h. Encryption - Network Security Policy: TLS 1.2 minimum in transit, AES-256 at rest via GCP-managed encryption, VPC isolation with prod separated from dev/test.
EDR (Endpoint Detection & Response) - Evidence	Task to Platform team
Encryption Documentation (In-Transit and At-Rest)	Network Security Policy - the primary evidence. In transit: all traffic between Appcircle services and between services and end users encrypted with TLS 1.2 minimum; unencrypted protocols not permitted for sensitive data. At rest: AES-256 via GCP-managed encryption on all production data stores and databases by default. Key management: secure generation, restricted access, storage, rotation and destruction, covering both Appcircle-managed and GCP KMS-managed keys, with sub-processors required to apply equivalent standards. Endpoint Device Security Policy - full-disk encryption: FileVault AES-XTS (macOS), BitLocker AES-256 (Windows), LUKS2/dm-crypt (Linux). Plus secure wipe before disposal or reassignment. Disaster Recovery Plan - Vault on a GCS backend with KMS auto-seal for secrets. Logging and Monitoring Policy - logs encrypted in transit to the central platform. Self-hosted TLS configuration (customer-configurable) is available.
Identity & Access Management Evidence	Task to Platform team
IDS Evidence	Task to Platform team
Patching Timelines	Task to Platform team
Penetration Testing Results	Can be given to customer if requested? or no?
Retention / Disposal Policy	data-retention-and-disposal-policy
Vulnerability Scan Results	Can be given to customer if requested? or no?
WAF (Web Application Firewall) Evidence	Task to Platform team