Information Security Overview

ATMList maintains a formal information security management system (ISMS) sponsored by executive management. The ISMS defines security roles and accountability, with the VP of Engineering serving as the designated security program lead and reporting on security posture to the executive team at least quarterly.

An information security steering committee reviews control effectiveness metrics, audit findings, risk treatment plans, and material security incidents. The committee includes representatives from engineering, product, legal, and operations functions to ensure cross-functional oversight.

A written information security policy framework is approved by executive management and communicated to all personnel. Policies are reviewed at least annually or upon significant changes to the operating environment, technology stack, or regulatory landscape.

• Executive-sponsored ISMS with defined roles: VP of Engineering as security program lead.
• Quarterly steering committee meetings with cross-functional representation.
• Annual policy review cycle with version-controlled policy repository.
• Board-level reporting on security posture at least annually.

ATMList conducts risk assessments at least annually for core production services and upon material changes to architecture, data flows, or processing activities. Assessments follow a structured methodology evaluating likelihood, impact, and existing control effectiveness.

Identified risks are recorded in a risk register with assigned owners, treatment decisions (accept, mitigate, transfer, or avoid), target remediation dates, and residual risk ratings. The register is reviewed during quarterly steering committee meetings.

Third-party risk assessments cover vendor and subprocessor engagements with logical access to production data or systems. Assessment scope includes security posture, data handling practices, business continuity arrangements, and contractual obligations.

Risk acceptance decisions for residual risks above defined thresholds require documented approval from the VP of Engineering or executive management, depending on severity level.

ATMList maintains a comprehensive suite of security policies aligned to SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 control families. Policies are version-controlled, approved by executive management, and accessible to all personnel.

The policy framework includes an overarching information security policy supported by topic-specific standards governing access control, cryptography, change management, logging and monitoring, vendor management, business continuity, and personnel security.

Compliance with policies is reinforced through new-hire acknowledgment, annual mandatory security awareness training, and periodic spot checks conducted by the security function. Policy exceptions require formal documented approval with defined expiration timelines.

• Overarching information security policy with topic-specific standards.
• SOC 2 and ISO/IEC 27001:2022 control alignment.
• Version-controlled, annually reviewed policy repository.
• Mandatory policy acknowledgment for all personnel with access to production systems.
• Formal exception management process with expiration and re-approval requirements.

ATMList conducts background screening on all employees and contractors with access to production systems, customer data, or corporate infrastructure, to the extent permitted by applicable local law. Screening is completed prior to granting system access and may include identity verification, employment history, and criminal record checks.

All personnel complete security awareness training during onboarding and at least annually thereafter. Training covers phishing awareness, password hygiene, data classification, incident reporting obligations, and acceptable use of corporate assets. Engineering personnel receive additional secure-development training.

Employment termination and role-change procedures include timely revocation of system access, return of corporate assets, and notification to dependent systems within one business day. Access removal is validated through automated provisioning and periodic access-certification reviews.

Confidentiality obligations are documented in employment and contractor agreements. Personnel are informed that unauthorized disclosure of customer or corporate information may result in disciplinary action up to and including termination and legal proceedings.

• Pre-engagement background screening for production-access personnel.
• Mandatory annual security awareness training with role-specific modules for engineers.
• One-business-day access revocation for terminations and role changes.
• Contractual confidentiality obligations for all employees and contractors.

ATMList maintains an inventory of information assets supporting production services, including compute instances, databases, object storage buckets, cryptographic key material, and SaaS platforms used for business operations. Assets are classified by sensitivity and criticality following a documented data-classification standard.

Data classification levels include Public, Internal, Confidential, and Restricted, with handling requirements defined for each tier. Customer Content is classified as Restricted and subject to the most stringent access, encryption, retention, and disposal controls.

Asset ownership is assigned to accountable individuals or teams. Lifecycle management procedures govern provisioning, maintenance, and decommissioning of production assets, including secure sanitization of storage media containing customer data prior to disposal or reallocation.

• Four-tier data classification standard: Public, Internal, Confidential, Restricted.
• Production asset inventory with assigned ownership.
• Customer Content classified as Restricted with elevated handling requirements.
• Secure media sanitization in accordance with documented decommissioning procedures.

ATMList enforces least-privilege and role-based access control (RBAC) across production environments. Access to production systems, databases, and customer data is restricted to personnel with a documented business need and granted only after manager approval and access-provisioning workflows.

Multi-factor authentication (MFA) is mandatory for all user accounts accessing production infrastructure, corporate identity providers, source-code repositories, and cloud-management consoles. MFA is enforced through time-based one-time passwords (TOTP) or FIDO2-compliant hardware security keys. Single-factor authentication is not permitted for production access.

Privileged access to production systems is further protected through just-in-time (JIT) elevation where technically feasible, session recording, and automated review of privileged command logs. Shared accounts are prohibited. Service accounts and API keys follow the principle of least privilege with minimal scope and regular rotation.

Access certifications are performed on a recurring quarterly basis, covering all user accounts with access to production systems and customer data. Managers review and attest to the appropriateness of access for their direct reports. Unused or unjustified access is revoked within five business days. Customer-facing applications provide organization-level RBAC with assignable roles for administrators, developers, and read-only users.

• RBAC with least-privilege enforcement across all production environments.
• Mandatory MFA via TOTP or FIDO2 for production-access accounts.
• JIT elevation for privileged operations where supported by the platform.
• Privileged session recording and automated log review.
• Quarterly access-certification reviews with five-business-day revocation SLA.
• Customer RBAC: administrator, developer, and read-only roles.

ATMList enforces encryption in transit using TLS 1.2 or higher (TLS 1.3 preferred) for all customer-facing endpoints, inter-service communication within production environments, and data transfers to subprocessors and third-party integrations. Insecure cipher suites and protocol versions are disabled through infrastructure-as-code configuration.

Customer Content is encrypted at rest using AES-256 or equivalent algorithms for primary databases, read replicas, object storage, file systems, and backups. Encryption keys for at-rest protection are managed through the cloud provider’s key management service (KMS) with automatic rotation enabled where supported.

Application-layer encryption keys for API authentication tokens, signing keys, and integration secrets are stored in a hardened secret-management service with fine-grained access policies, audit logging, and separation from application runtime environments. Secrets are never written to application logs, source code, or configuration files in cleartext.

Key management procedures define key generation, rotation, revocation, and destruction lifecycles. Cryptographic key material is generated using approved algorithms and key lengths. Access to key material is restricted to automated service identities and a minimal set of authorized personnel with MFA and JIT elevation requirements.

• TLS 1.2+ (1.3 preferred) for all customer-facing and inter-service traffic.
• AES-256 encryption at rest for databases, object storage, and backups.
• Cloud KMS with automatic key rotation for at-rest encryption keys.
• Hardened secret-management service for application secrets and API keys.
• Prohibition on storing secrets in logs, source code, or configuration files.
• Key lifecycle management: generation, rotation, revocation, and destruction procedures.

ATMList production environments employ a defense-in-depth network architecture with logical segmentation between ingress, application, and data tiers. Default-deny network policies govern communication between services, with explicit allow-list rules defined per workload based on functional requirements.

Web application firewalls (WAFs) protect customer-facing endpoints against common attack patterns, including OWASP Top 10 vulnerabilities. Rate limiting and IP reputation filtering are applied at the ingress layer to mitigate volumetric and credential-stuffing attacks.

DDoS mitigation services are deployed at the network edge to absorb and filter volumetric attacks before they reach application infrastructure. Internal network monitoring detects anomalous traffic patterns indicative of lateral movement or data exfiltration attempts.

Remote administrative access to production infrastructure is restricted to VPN or zero-trust network access solutions with MFA enforcement, session timeouts, and audit logging. Direct exposure of administrative interfaces to the public internet is prohibited.

• Tiered network segmentation: ingress, application, and data layers.
• Default-deny service-to-service communication with explicit allow-lists.
• WAF with OWASP Top 10 protection for customer-facing endpoints.
• DDoS mitigation at the network edge.
• VPN or zero-trust network access for remote administration with MFA.
• No direct public-internet exposure of administrative interfaces.

ATMList collects, aggregates, and correlates security-relevant events from production infrastructure, application layers, access management systems, and network devices. Log sources include operating system logs, application logs, API gateway access logs, database audit logs, identity-provider authentication events, and cloud-platform control-plane activity.

Centralized log aggregation feeds into a security information and event management (SIEM) system with detection rules covering known attack patterns, anomalous access behavior, privilege escalation, configuration drift, and data exfiltration indicators. Alerts are triaged by on-call engineering personnel with defined severity classifications and escalation paths.

Log integrity is protected through write-once-read-many (WORM) storage where technically feasible, access controls restricting log modification, and retention periods defined by operational and compliance requirements. Security logs are retained for a minimum of twelve months for investigation and forensic purposes.

Logging infrastructure is monitored for availability and ingestion health. Gaps in log collection or processing trigger automated alerts. Sensitive data redaction rules prevent the inadvertent logging of authentication secrets, personal data, or payment card information in cleartext.

• Centralized log aggregation from infrastructure, application, and identity layers.
• SIEM with automated detection rules for known and anomalous threat patterns.
• On-call triage with severity-based classification and escalation paths.
• Minimum twelve-month security-log retention.
• Sensitive-data redaction in log pipelines.
• WORM storage and access controls for log integrity protection.

ATMList conducts vulnerability scanning across production infrastructure on a continuous basis. Scanning covers operating systems, container images, application dependencies, and network-accessible services. Scans are scheduled automatically and supplemented by ad-hoc scans triggered by significant infrastructure changes or emerging threat intelligence.

Identified vulnerabilities are prioritized by severity using CVSS scores augmented by exploitability context, asset criticality, and exposure analysis. Remediation SLAs are defined per severity tier: critical vulnerabilities are triaged within 24 hours with remediation targeted within 7 days; high-severity findings are addressed within 30 days; medium and low findings are scheduled within recurring maintenance windows.

Container images and third-party dependencies are scanned during CI/CD pipelines prior to deployment. Images with critical or high-severity known vulnerabilities are blocked from promotion to production unless an approved exemption is documented with compensating controls and a defined remediation timeline.

ATMList engages independent third-party penetration testers at least annually to assess the security of production API endpoints, web applications, and supporting infrastructure. Test scope covers OWASP Top 10, API-specific attack vectors, and cloud-configuration weaknesses. Executive summaries are available to qualified customers under NDA. Remediation findings are tracked to closure in the vulnerability management system.

• Continuous vulnerability scanning across OS, containers, dependencies, and network services.
• CVSS-based prioritization with context-aware severity augmentation.
• Severity-tiered remediation SLAs: critical (7 days), high (30 days), medium/low (maintenance windows).
• CI/CD pipeline scanning with blocking gates for critical/high findings.
• Annual independent third-party penetration testing.
• Vulnerability findings tracked to closure with documented compensating controls.

ATMList follows a secure software development lifecycle (SDLC) integrating security activities from design through deployment. All application changes undergo mandatory peer code review by at least one qualified reviewer, automated static analysis, and comprehensive automated testing before promotion.

Changes are deployed through a staged pipeline: development, staging, and production environments, with each stage gated by automated security and functional test suites. Separation of duties is enforced between development and production deployment roles. Direct production changes outside the defined pipeline are prohibited and flagged as policy violations.

Infrastructure changes follow infrastructure-as-code (IaC) practices with version-controlled templates, peer review, and automated policy-as-code checks for security misconfigurations. Drift detection monitors for divergence between declared and actual infrastructure state.

Emergency changes bypassing standard change windows require documented justification, post-hoc review within one business day, and automated notification to the security function. All changes, including emergency fixes, are recorded in an immutable audit trail with attributable actor identity.

• Mandatory peer code review with at least one qualified reviewer.
• Staged deployment pipeline: development, staging, production.
• Separation of duties between development and production deployment roles.
• Infrastructure-as-code with peer review and policy-as-code validation.
• Emergency change procedure with one-business-day post-hoc review.
• Immutable audit trail for all changes with attributable identity.

ATMList operates production services across multiple availability zones within its primary cloud region, with stateless application tiers designed for automatic failover and data tiers configured with synchronous or asynchronous replication depending on latency and durability requirements.

Database backups are performed on a continuous or daily schedule, depending on the data store, with point-in-time recovery (PITR) enabled where supported. Backups are encrypted at rest, stored in a geographically separate facility, and tested for restorability on a defined quarterly cadence. Backup retention periods meet or exceed documented recovery objectives.

A business continuity plan (BCP) and disaster recovery plan (DRP) define recovery time objectives (RTO) and recovery point objectives (RPO) for core API services. The DRP is tested at least annually through tabletop exercises and technical recovery simulations. Test results are documented, and corrective actions are tracked to closure.

Business continuity planning extends to critical third-party dependencies, including cloud infrastructure providers and key subprocessors. Dependency risk is assessed during onboarding and re-evaluated annually. Alternate processing arrangements or redundancy measures are maintained for services identified as single points of failure.

• Multi-AZ production deployment with automatic failover for stateless tiers.
• Continuous or daily encrypted backups with point-in-time recovery capability.
• Quarterly backup-restoration testing.
• Documented RTO and RPO for core API services.
• Annual DRP testing: tabletop exercises and technical recovery simulations.
• Third-party dependency risk assessment and alternate processing arrangements.

ATMList maintains a vendor management program requiring security assessment of third parties with logical or physical access to production data, systems, or facilities prior to engagement. Assessments evaluate security certifications (SOC 2, ISO 27001), data handling practices, incident response capability, and financial stability.

Subprocessors engaged in processing Customer Content are listed in a publicly maintained subprocessor annex. ATMList imposes data-protection and security obligations on all subprocessors through written agreements no less protective than ATMList’s own commitments, including confidentiality, breach notification timelines, and secure deletion upon termination.

Subprocessor security posture is reassessed at least annually or upon material changes to the subprocessor’s control environment. ATMList reserves the right to suspend or terminate subprocessor relationships where reassessment identifies unacceptable risk that cannot be mitigated within agreed timeframes.

Notifications of new subprocessor engagements or material changes to existing subprocessor arrangements are provided to customers in accordance with the Data Processing Agreement, allowing customers to raise objections on reasonable data-protection grounds.

• Pre-engagement security assessment for vendors with production access.
• Public subprocessor annex maintained on ATMList website.
• Written agreements imposing equivalent security and data-protection obligations.
• Annual subprocessor reassessment cycle.
• Customer notification and objection process for new subprocessor engagements.

ATMList production infrastructure is hosted in commercial cloud data centers that maintain SOC 2 Type II and ISO/IEC 27001 certifications. ATMList does not operate its own physical data centers. Physical security of underlying infrastructure is delegated to cloud providers and verified through their audit reports reviewed during the vendor management process.

Cloud provider physical controls include perimeter fencing, 24/7 on-site security personnel, biometric access controls, video surveillance with retention, redundant power and environmental systems, and fire detection and suppression. ATMList reviews provider SOC 2 and ISO 27001 reports at least annually to validate continued adequacy of physical safeguards.

ATMList corporate office access is controlled through badge-based entry systems with visitor logging and escort requirements. Workstations are configured with full-disk encryption, automatic screen locking, and remote-wipe capability through the corporate device management platform.

• Production infrastructure hosted in SOC 2 and ISO 27001 certified cloud data centers.
• Annual review of cloud-provider audit reports.
• Corporate office: badge-based access, visitor logging, escort policy.
• Endpoint controls: full-disk encryption, auto-lock, remote-wipe capability.

ATMList maintains a documented incident response plan defining roles, responsibilities, and procedures for security incident identification, classification, containment, eradication, recovery, and post-incident review. The plan covers incidents affecting production availability, data confidentiality, and system integrity.

Incidents are classified by severity level — Critical, High, Medium, or Low — based on impact to customer data, service availability, and regulatory exposure. Classification triggers predefined escalation paths, notification timelines, and response-team composition. Critical incidents invoke immediate executive notification and dedicated war-room coordination.

ATMList shall notify affected customers without undue delay following confirmation of a security incident involving unauthorized access to, or exfiltration of, Customer Content. Notifications include a description of the incident, the nature of affected data, mitigation actions taken or planned, and contact information for ongoing communication. Enterprise agreements may specify additional notification timeframes and content requirements.

Post-incident reviews are conducted for all Critical and High-severity incidents. Findings are documented with root-cause analysis, corrective actions, and control improvements. Relevant lessons learned are incorporated into security awareness training and control-design reviews.

• Documented incident response plan: identification through post-incident review.
• Four-tier severity classification: Critical, High, Medium, Low.
• Customer notification without undue delay for confirmed breaches of Customer Content.
• Post-incident reviews with root-cause analysis for Critical and High-severity incidents.
• Lessons learned incorporated into security training and control improvements.

ATMList operates under a shared-responsibility model. ATMList is responsible for the security of the platform, including infrastructure, application, and data-processing controls described in this document. Customers are responsible for the security of their accounts, API credentials, applications integrating with ATMList services, and end-user devices.

Customers must configure account-level RBAC appropriately, protect API keys and authentication secrets, implement secure coding practices in consuming applications, and promptly notify ATMList of suspected unauthorized access to their accounts. Credentials exposed in client-side code, public repositories, or logs remain the customer’s responsibility.

Customers processing personal data through ATMList services must ensure their use comports with applicable data-protection law, including establishing a lawful basis for processing, providing transparency notices to data subjects, and fulfilling data-subject rights requests for which ATMList provides reasonable assistance as defined in the Data Processing Agreement.

Customers conducting their own security assessments are encouraged to leverage SOC 2 Type II reports, penetration-test executive summaries, and security questionnaires available through the vendor-security portal rather than performing direct infrastructure testing, which requires prior written authorization from the ATMList security team.

• Shared-responsibility model: ATMList secures the platform; customer secures accounts and integrations.
• Customer obligation to protect API keys and authentication secrets.
• Customer responsible for lawful basis and transparency notices for personal data processing.
• Direct customer infrastructure testing requires prior written authorization.

ATMList undergoes an independent SOC 2 Type II examination annually, covering the Security and Availability Trust Services Criteria relevant to the ATMList production platform. The examination is conducted by a licensed CPA firm. Report availability is subject to non-disclosure agreement and is restricted to qualified customers and prospects.

ATMList aligns its ISMS to ISO/IEC 27001:2022 control objectives. While ATMList does not currently hold an accredited ISO 27001 certification, the control framework is mapped to Annex A controls, and the organization maintains evidence artifacts suitable for customer due-diligence assessments referencing ISO 27001 requirements.

ATMList’s Data Processing Agreement addresses GDPR Article 28 processor obligations and UK GDPR equivalent provisions. Standard Contractual Clauses (EU SCCs, Module Two or Three as applicable, and the UK International Data Transfer Addendum) are incorporated by reference for customers requiring documented transfer mechanisms for personal data originating in the EEA, UK, or Switzerland.

• Annual SOC 2 Type II examination covering Security and Availability criteria.
• ISMS aligned to ISO/IEC 27001:2022 Annex A controls with evidence artifacts for customer assessments.
• GDPR Article 28 processor obligations addressed in Data Processing Agreement.
• EU SCCs and UK International Data Transfer Addendum incorporated by reference.

ATMList processes personal data in accordance with its Global Privacy Policy and Data Processing Agreement. Customer Content is processed in the cloud region(s) selected by the customer at service onboarding. ATMList may process metadata, telemetry, and service-operation data in additional regions for security monitoring and platform operations.

Customer Content processed in ATMList’s primary production region — Tokyo, Japan — benefits from Japan’s adequacy recognition under the GDPR and UK GDPR. Customers requiring data residency in additional regions beyond those currently offered should engage ATMList’s commercial team to discuss roadmap and custom deployment options.

ATMList performs privacy impact assessments for new processing activities, product features, or subprocessor engagements that may materially affect the privacy posture of customer personal data. Assessments are documented and reviewed by the legal and security functions.

• Customer Content processed in customer-selected cloud region(s).
• Primary processing region (Tokyo, Japan) recognized as adequate under GDPR and UK GDPR.
• Privacy impact assessments for material processing changes.
• Metadata and telemetry may be processed in additional regions for security operations.

ATMList commissions independent third-party penetration tests at least annually, supplemented by targeted retests following significant architectural changes or major feature releases affecting authentication, authorization, or data-processing flows. Testing methodology aligns with OWASP Testing Guide, PTES, and cloud-specific attack frameworks.

Penetration test scope includes public-facing API endpoints, authentication mechanisms, authorization models, tenant-isolation boundaries, and cloud-configuration posture. Both authenticated and unauthenticated testing perspectives are employed. Findings are categorized by severity using a CVSS-derived rating scale and tracked through the vulnerability management lifecycle.

Executive summaries of the most recent penetration test are available to qualified customers under NDA. ATMList encourages customers to leverage these summaries in lieu of conducting independent penetration testing, which requires prior coordination and written authorization from the ATMList security team to avoid impacting shared infrastructure.

• Annual independent third-party penetration testing with supplemental retests.
• Scope: API endpoints, authentication, authorization, tenant isolation, cloud configuration.
• OWASP-aligned testing methodology with authenticated and unauthenticated perspectives.
• Executive summaries available to customers under NDA.

ATMList supports customer security assessments through multiple channels: SOC 2 Type II reports, standardized security questionnaires (CAIQ-Lite or custom formats upon request), penetration-test executive summaries, and control-mapping worksheets aligned to common frameworks including SOC 2, ISO 27001, NIST CSF, and PCI DSS referenced controls.

Standardized security questionnaire responses are updated at least annually or upon material changes to the control environment. Responses are reviewed by the security function for accuracy and completeness before distribution. ATMList may decline to answer questions exceeding the scope of audited controls or requiring disclosure of sensitive architectural detail.

On-site audits are available for strategic enterprise accounts subject to scheduling with at least 45 days’ notice, scope agreement, and reimbursement of reasonable costs where applicable. On-site audit frequency is limited to once per twelve-month period except where mandated by a supervisory authority or regulatory requirement.

Customers should direct security assessment requests, questionnaire submissions, and audit scheduling inquiries to the information-security mailbox. Acknowledgment is provided within three business days. Questionnaire turnaround targets fifteen business days from receipt of a complete request.

• Multiple assessment channels: SOC 2 reports, standardized questionnaires, penetration-test summaries.
• CAIQ-Lite or custom-format security questionnaire support.
• Annual update cycle for standardized questionnaire responses.
• On-site audits: 45-day notice, annual frequency limit, scope agreement required.
• Three-business-day acknowledgment; fifteen-business-day questionnaire turnaround target.

ATMList accepts good-faith vulnerability reports submitted to the information-security mailbox or via the coordinated vulnerability disclosure program accessible through the trust center. Reports must include sufficient technical detail to reproduce the issue, including affected endpoints, request payloads, and observed behavior.

Security researchers must avoid privacy violations, data exfiltration, destruction or modification of data, and service degradation during testing. Research activities causing denial-of-service conditions, performing automated scanning at aggressive rates, or accessing customer data beyond proof-of-concept scope are prohibited and may result in legal action.

ATMList commits to acknowledging vulnerability reports within three business days and providing a validated assessment within fifteen business days where feasible. ATMList will not initiate legal action against researchers who comply with this section, make a good-faith effort to avoid harm, and allow reasonable time for remediation prior to public disclosure.

ATMList does not operate a paid bug-bounty program as of the effective date of this document. Researchers reporting qualifying vulnerabilities may receive public acknowledgment (with consent) in the security hall-of-fame or security advisories.

• Vulnerability reports accepted via security mailbox or trust-center disclosure program.
• Three-business-day acknowledgment target; fifteen-business-day validated assessment target.
• Safe-harbor commitment for researchers complying with disclosure terms.
• No paid bug-bounty program; voluntary researcher acknowledgment available.