Question 1

What data does Secure.com ingest?

Accepted Answer

Secure.com connects to the security, cloud, identity, development, and IT systems a customer chooses to integrate, and analyzes the security telemetry and operational context those systems expose. Depending on which integrations are enabled, this can include: Security findings, alerts, vulnerabilities, and incidents Asset, application, workload, and identity metadata Configuration and control-status information Cloud, endpoint, network, and application-security telemetry Ticketing, case-management, and remediation status Compliance evidence and control-mapping information Workflow definitions and response instructions authorized by the customer Organizational information such as employee names, roles, and business contact details, used for collaboration, workflow routing, approvals, and identity-driven security Natural language queries submitted to the platform’s conversational interface, together with the responses returned Secure.com provides a natural language interface for querying security data. Queries submitted through it, and the responses returned, are recorded and retained within the customer’s tenant under the same retention terms as other customer data, so that what was asked and what was answered remain reviewable. Secure.com ingests what is required to understand, prioritize, investigate, and coordinate security activity. It does not require access to general business content, source repositories, or communications outside the scope of an enabled integration.

Question 2

Does Secure.com process personal data?

Accepted Answer

Secure.com does not intentionally gather personally identifiable information. The platform is built to analyse security posture and activity, not individuals, and no integration is designed to collect personal data for its own sake. That said, security telemetry is not free of personal data, and it would be misleading to suggest otherwise. Identity records, asset ownership, endpoint attribution, user activity logs, IP addresses, and the organizational contact information used for workflow routing are personal data under GDPR and comparable regimes, and Secure.com processes them where a customer’s integrations supply them. Secure.com acts as a processor for this data. It is processed only on documented customer instruction and only to deliver the service, and data minimization is applied at the integration level so that only fields relevant to the security use case are retrieved.

Question 3

How long is customer data retained?

Accepted Answer

Customer data is retained for three months by default. This applies across data classes, including security findings and case records, ingested telemetry, natural language queries and their responses, model interaction records, and audit logs. Retention is configurable beyond the default. Longer or shorter periods are available depending on the subscription package, and a specific retention period can be agreed as a customised requirement where a customer’s regulatory or operational obligations call for one. The agreed period is recorded in the customer agreement, and retention beyond it occurs only where required by contract or law.

Question 4

Can customers request deletion or export of their data?

Accepted Answer

Yes. Customers may export their data at any time during the subscription term. On termination, a defined sequence applies: Export window — 30 days. Customer data remains available for export for thirty days from the termination date. Archive — a further 30 days. After the export window closes, data is moved to archive for thirty days, during which it is no longer available in-product but can still be recovered if the customer identifies an error or requests reinstatement. Deletion from backups — as cycles expire. Once the archive period ends, data is removed from production systems, and remaining copies age out of backup media as scheduled backup cycles complete. Customers requiring deletion certification, or a shorter timeline than the sequence above, should raise it during contracting.

Question 5

Does Secure.com sell customer data?

Accepted Answer

No. Secure.com has no advertising business, no data-brokerage relationships, and no revenue line derived from customer data. Specifically: Customer data is not sold, licensed, or rented to third parties for their own commercial purposes. It is not shared with data brokers, advertising networks, or marketing platforms. It is not used for advertising, nor to build or enrich any profile of a customer, its people, or its assets for any purpose outside delivering the service to that customer. Customer data is used to deliver the service to the customer that supplied it. Third parties that process customer data do so as subprocessors, are listed with their purpose and the categories of data they process, and are contractually bound to obligations no less protective than Secure.com’s own commitments to customers.

Question 6

Does Secure.com use customer data to improve its products?

Accepted Answer

Secure.com collects operational telemetry about the platform itself — service availability, latency, error rates, throughput, and how platform features are used — in the way any service provider does to run and support a service. This telemetry is used to: monitor service delivery and performance against service level commitments; detect, diagnose, and resolve errors and degradations; understand usability and identify where the product is difficult to use; plan capacity and prioritise engineering work. This is telemetry about the operation of the platform, not about the content of a customer’s security data. Customer security findings, case content, credentials, prompts, and identifiable asset or user information are not used to train models, are not pooled into a cross-customer dataset, and are not used for any purpose other than delivering the service to that customer.

Question 7

Where is customer data stored and processed?

Accepted Answer

Customer data is stored and processed in one of two Amazon Web Services regions: AWS Europe (Frankfurt) — eu-central-1 AWS US East (Northern Virginia) — us-east-1 Foundation-model inference is performed through Amazon Bedrock within the same AWS region, so prompts and the responses returned to them are processed inside the region rather than being routed elsewhere. Where a customer requires a region other than the two above, Secure.com treats it as a customised requirement and will confirm whether it is feasible, and on what commercial terms, during scoping.

Question 8

Does Secure.com support data residency requirements?

Accepted Answer

Yes, within the two regions listed above. Customers with EU or UK residency requirements can be provisioned in Frankfurt; customers with US residency requirements can be provisioned in Northern Virginia. Where a customer requires a region Secure.com does not currently operate, it is assessed as a customised requirement on grounds of technical feasibility and commercial viability. Secure.com will say plainly whether a region can be delivered and by when, rather than accepting a residency requirement conditionally and resolving it later.

Question 9

Can Secure.com operate in restricted or disconnected environments?

Accepted Answer

Restricted-connectivity deployments are assessed case by case. Capabilities that depend on external model inference or threat-intelligence updates may be limited or unavailable in fully disconnected environments, and Secure.com will identify those limitations during scoping.

Question 10

How is customer data isolated?

Accepted Answer

Each customer environment is logically segregated through tenant-scoped identifiers enforced at the data, application, and API layers. Every request carries a tenant context, and records are retrievable only within the tenant that owns them. Isolation controls are tested as part of Secure.com’s security testing programme. As described in Section 2, logical segregation is the isolation model for the standard service. Physical or infrastructure-level separation is not part of the standard offering; where a customer requires it, it is assessed as a customised requirement.

Question 11

How does Secure.com control access to customer environments?

Accepted Answer

Access is governed by role-based access control, least privilege, and separation of duties. Access is provisioned according to the individual’s role, authentication to Secure.com systems requires multifactor authentication, and role assignments are reviewed periodically to confirm that access remains appropriate and least-privileged. On termination of employment or engagement, access to all in-scope systems is deprovisioned as part of a documented offboarding process. Secure.com personnel do not hold standing access to customer data or customer workspaces. Where access to a customer’s workspace is required — typically for support, troubleshooting — it is authorised by the customer. Access is requested and approved against a defined purpose, granted for a limited period, exercised under an individually attributable identity, logged, and withdrawn when the purpose is complete. These access controls were examined as part of Secure.com’s SOC 2 Type 2 audit.

Question 12

Does Secure.com support single sign-on and multifactor authentication?

Accepted Answer

Yes. Secure.com supports single sign-on using SAML 2.0 and OpenID Connect, allowing customers to authenticate users through their existing identity provider and to apply their own authentication policies, session controls, and conditional access rules. Multifactor authentication is available and is required for authentication to Secure.com’s own systems. Customers are responsible for enabling and maintaining multifactor authentication for their own users, as set out in Section 14.

Question 13

Are privileged actions logged?

Accepted Answer

Yes. Administrative activity, permission changes, integration changes, workflow execution, approvals, and Digital Security Teammate actions are all logged, each attributable to the identity that performed it. Audit logs are retained in line with the agreed data retention period — three months by default, as described in Section 1 — and are available to customers in-product.

Question 14

How does Secure.com secure integration credentials?

Accepted Answer

Integration credentials and secrets are stored encrypted in a dedicated secrets management vault, scoped to a single tenant, accessible only to the services that require them, and never exposed in logs, model prompts, or user interfaces. Secure.com recommends and supports least-privilege scoping for every integration, and publishes the minimum permission set required for each.

Question 15

What AI models does Secure.com use?

Accepted Answer

Secure.com does not depend on a single foundation model. Inference is delivered through Amazon Bedrock, the managed AWS service that provides access to foundation models by API, and the platform selects between Claude Opus, Claude Sonnet, and Claude Haiku according to what the task requires. The selection balances depth of reasoning against latency and cost. Complex investigative reasoning, correlation across large context, and judgement-heavy analysis are routed to more capable models; high-volume, well-bounded steps such as classification, extraction, and enrichment are routed to faster ones. Routing is determined by the nature of the task rather than by the customer. Secure.com combines this inference with proprietary models and deterministic analytical components, so that a conclusion is rarely the product of a language model alone. Each provider is identified in the subprocessor list along with its purpose and processing location.

Question 16

Is customer data used to train foundation models?

Accepted Answer

No. Customer data is not used to train foundation models, whether third-party or proprietary to Secure.com. The architecture is the reason this can be stated without qualification. Inference is served by Amazon Bedrock inside Secure.com’s own AWS environment, in the AWS region the customer selected. Under the AWS Bedrock service terms, prompts and completions are not used to train the underlying foundation models, are not shared with the model providers, and are not retained by the service after a request has been served. Prompts therefore do not transit a separate model vendor’s infrastructure and do not leave the AWS boundary or the selected region. Prompts and responses are recorded within the customer’s own tenant, as described in Section 1, so the customer retains a reviewable record without any copy being created outside their environment.

Question 17

Is customer data shared across customers?

Accepted Answer

No. Customer data, context, prompts, outputs, and findings are confined to that customer’s tenant and are not exposed to other customers. This holds at each layer of the platform: Storage and application — records are tenant-scoped, enforced at the data, application, and API layers as described in Section 3. Model interactions — each model request is constructed within a single tenant boundary and carries only the context required for the specific task. No request assembles context drawn from more than one customer. Prompts and outputs — logged inside the originating customer’s tenant rather than in a shared pool. Findings and cases — a finding produced in one environment is not surfaced, referenced, or used as supporting evidence in another. Credentials and secrets — integration credentials are scoped to a single tenant and are not shared between customers or between Digital Security Teammates. The operational telemetry described in Section 1 concerns the performance and usage of the platform itself, not the content of customer security data, and creates no flow of customer data between tenants.

Question 18

How are model interactions isolated?

Accepted Answer

Model requests are constructed within tenant boundaries and carry only the context required for the specific task. Prompts and outputs are logged within the customer’s tenant. Secrets, credentials, and excluded fields are filtered before any model call.

Question 19

Can customers choose which models are used?

Accepted Answer

Model selection is managed by Secure.com rather than configured by the customer. The platform routes each task to the model best suited to it, and that routing is part of how Secure.com controls quality, latency, and cost across the service. Where a customer has a specific model-risk, privacy, or sovereignty requirement, Secure.com will assess it as a customised requirement. Whether it can be accommodated depends on technical feasibility and on the capability differences between models: constraining the platform to a narrower set of models can affect the depth of analysis or the latency of a response, and in some cases both. Secure.com will set out those trade-offs during scoping rather than accept a constraint that would quietly degrade the service.

Question 20

Can models run inside the customer’s environment?

Accepted Answer

Customer-hosted inference is supported for approved model architectures in customer-controlled deployments. Capability differences relative to the managed service are documented during scoping.

Question 21

Do model providers retain prompts or outputs?

Accepted Answer

Secure.com’s enterprise arrangements with model providers restrict retention to what is required for abuse monitoring, where the provider requires it at all, and prohibit training on submitted data. Retention terms for each provider are summarized in the subprocessor list.

Question 22

How does Secure.com reduce incorrect or fabricated conclusions?

Accepted Answer

Three controls apply, in order of precedence. First, human oversight. Actions carrying material impact require explicit human approval before they execute, regardless of the confidence attached to the underlying conclusion. A person reviews the recommendation together with the evidence that produced it and decides. A high-confidence conclusion does not bypass this; confidence determines how a recommendation is presented, not whether a human is required. Second, pre-approved execution. Where a customer has deliberately pre-approved a defined action for a defined situation, the platform may carry it out without seeking fresh approval each time — but only inside the boundary the customer set, and only for the action types the customer nominated. Third, guardrails. All execution, whether individually approved or pre-approved, runs inside technical constraints that hold irrespective of what the model concluded: permitted action types are allowlisted, the agent’s identity carries only the permissions the customer granted, actions are scoped by environment and asset, and destructive operations are gated by default. Underpinning all three, model outputs are grounded in structured security data retrieved from the customer’s own systems rather than generated from model recall. Conclusions are constrained by deterministic logic, validated against source evidence, scored for confidence, and surfaced together with the findings that produced them, so a reviewer can see the basis for a recommendation rather than being asked to trust it. Secure.com evaluates model and workflow accuracy against held-out security datasets before release and monitors output quality in production.

Question 23

Are AI-generated actions fully autonomous?

Accepted Answer

Automation level is a customer policy decision. Secure.com supports advisory-only operation, approval-gated execution, and pre-approved autonomous execution within defined guardrails. High-impact actions can be required to carry explicit human approval regardless of confidence score.

Question 24

Can customers disable automated execution entirely?

Accepted Answer

Yes. Secure.com can operate in advisory-only mode, in which Digital Security Teammates analyze and recommend but take no action in customer systems.

Question 25

How does Secure.com defend against prompt injection?

Accepted Answer

Security telemetry is attacker-influenced by design: alert names, file paths, commit messages, ticket text, and hostnames can all carry adversarial instructions. Secure.com treats all ingested content as untrusted input and does not allow it to alter agent instructions. Controls include structural separation of instructions from data, allowlisting of the actions an agent may take rather than open-ended tool access, validation of every proposed action against policy before execution, and approval requirements on high-impact actions that hold regardless of what the input asks for. The execution architecture reinforces this. Inference is served by Amazon Bedrock within Secure.com’s own AWS environment, so untrusted customer telemetry is never submitted to a shared public model endpoint. More importantly, a successful injection cannot escalate into unauthorised action: what an agent is permitted to do is determined by its provisioned identity, the allowlist, and the customer’s approval policy, none of which the model can alter. Manipulating what a model concludes and expanding what it is allowed to do are separate problems, and only the second is capable of causing harm in a customer environment.

Question 26

How do Digital Security Teammates authenticate to customer systems?

Accepted Answer

Each Teammate operates under a distinct, customer-provisioned identity scoped to the integrations and permissions the customer grants. Credentials are not shared between Teammates or between customers, actions are attributable to a specific agent identity in customer logs, and permissions can be revoked independently.

Question 27

How is the blast radius of an agent limited?

Accepted Answer

Agent authority is bounded by the permissions of its identity, the allowlist of permitted action types, environment and asset scoping, rate and volume limits on repeated actions, and approval gates on destructive or high-impact operations.

Question 28

Can an agent be stopped mid-execution?

Accepted Answer

Yes. Customers can suspend an individual workflow, disable a Teammate, or revoke integration credentials to halt all activity. Suspension takes effect immediately and in-flight actions are cancelled where technically possible.

Question 29

How does Secure.com test agent behavior before release?

Accepted Answer

Agent capabilities are tested against adversarial inputs, including injection attempts embedded in realistic security telemetry, before release and on an ongoing basis. Testing covers both the model layer and the execution layer: whether a crafted input can change what the model concludes, and separately whether it can cause an action outside the agent’s permitted scope. Because model routing spans several models, behaviour is evaluated across the models the platform selects between rather than against one of them. Findings are tracked through Secure.com’s vulnerability management process.

Question 30

Can agent activity be reviewed after the fact?

Accepted Answer

Yes. Secure.com records the finding that triggered a workflow, the context retrieved, the recommendation produced, the approval given, the action taken, and the outcome. These records support post-incident review, audit, and dispute resolution.

Question 31

What does human-in-the-loop mean at Secure.com?

Accepted Answer

Customers retain authority over consequential security decisions. Secure.com analyzes, recommends, coordinates, and executes; the customer defines where human approval is required and who may give it.

Question 32

Are workflows customer controlled?

Accepted Answer

Yes, and customers build as well as configure them. Secure.com maintains a library of pre-built workflows covering common detection, investigation, and remediation patterns. A customer can fork any of these into their own environment and adapt it — changing triggers, conditions, thresholds, the systems it touches, and the actions it is permitted to take — so that a starting point does not become a constraint. Customers can also author entirely custom workflows where the library does not cover a requirement. In both cases the customer determines which workflows are enabled, which systems they may access, which actions are permitted, and which approvals are required. New and modified workflows can be run in observation mode, where the platform produces recommendations without acting, before execution is enabled.

Question 33

Can automated actions be audited?

Accepted Answer

Yes, and the record is intended to reconstruct a complete decision chain rather than merely note that something happened. For each automated or semi-automated action, Secure.com records: the finding or event that triggered the workflow; the context retrieved from customer systems in order to assess it; the recommendation produced, and the confidence attached to it; the approval given, by whom and when — or the fact that the action fell inside a pre-approved guardrail; the action taken, against which target system, under which agent identity; the outcome returned by the target system. Because each Digital Security Teammate operates under a distinct, customer-provisioned identity, actions are independently attributable in the customer’s own logs and not only in Secure.com’s, so the record can be corroborated from outside the platform. These records are available in-product and are intended to support post-incident review, internal audit, regulatory examination, and dispute resolution.

Question 34

Can actions be overridden or reversed?

Accepted Answer

Customers can suspend workflows, revoke permissions, and modify policies at any time. Whether a specific action can be reversed depends on the target system; Secure.com identifies non-reversible action types and recommends approval gates on them by default.

Question 35

How is data protected in transit and at rest?

Accepted Answer

Customer data is encrypted both in transit and at rest, following current industry practice at each layer. In transit. All connections between customer systems, the platform, and integrated third-party services are encrypted using current versions of Transport Layer Security. Deprecated protocol versions and weak cipher suites are disabled, and certificates are managed and rotated centrally. Traffic between internal platform services is encrypted as well, so that encryption is not applied only at the perimeter. At rest. Data is encrypted in the underlying storage, database, and backup layers using strong, industry-standard symmetric encryption. Encryption is applied to primary storage, object storage, and backup media alike, so that a copy of data is not left unprotected because of where it sits in its lifecycle. Key management. Encryption keys are held in a managed key service, access to them is restricted to the services that require them, key use is logged, and keys are rotated on a defined cycle. Keys are never embedded in application code or configuration. Encryption is one layer among several rather than the whole of the control set. It is supported by the tenant segregation described in Section 3, by access control and logging, and by the network controls applied within the hosting environment.

Question 36

How does Secure.com manage vulnerabilities?

Accepted Answer

Secure.com runs continuous dependency and container scanning, static and dynamic application security testing, and infrastructure configuration monitoring. Findings are prioritized by severity and exploitability and remediated against defined timelines: critical within 7 days, high within 30 days.

Question 37

Does Secure.com conduct penetration testing?

Accepted Answer

Yes. Secure.com engages reputable independent third-party firms — preferring established international assurance practices — to perform vulnerability assessment and penetration testing against the production environment. Testing is conducted annually, and additionally following any significant change to the platform, so that material architectural change is not carried through to the next scheduled cycle untested. Automated vulnerability scanning runs monthly alongside the engagement, and findings from both feed into the same remediation process described above. A summary letter is available through the Trust Center, and the full report under NDA.

Question 38

How does Secure.com manage software supply-chain risk?

Accepted Answer

Secure.com maintains a software bill of materials, monitors dependencies for known vulnerabilities, restricts direct commits to protected branches, requires peer review and automated security checks before merge, and signs build artifacts.

Question 39

How is the development lifecycle protected?

Accepted Answer

Security controls are applied at each stage of development rather than only before release. Design — security requirements are defined as part of the design of a change, and threat modeling is applied to significant changes. Development — direct commits to protected branches are restricted, so a change reaches the main line only through review. Review — peer code review is mandatory. No change merges on its author’s approval alone. Automated verification — static and dynamic application security testing, dependency scanning, and container scanning run in the pipeline, and automated security checks must pass before a merge is permitted. Build and release — build artifacts are signed, and releases follow change management with documented rollback procedures. After release — infrastructure configuration is monitored continuously, and findings enter the vulnerability management process described above.

Question 40

Does Secure.com provide audit logs to customers?

Accepted Answer

Yes. Administrative, authentication, integration, workflow, and agent activity logs are available to customers in-product, retained in line with the agreed data retention period described in Section 1.

Question 41

Does Secure.com operate a vulnerability disclosure program?

Accepted Answer

Yes. Researchers can report suspected vulnerabilities to security@secure.com. Secure.com’s vulnerability disclosure policy and security.txt set out scope, expected response times, and safe-harbor commitments.

Question 42

Can customers conduct their own security testing of Secure.com?

Accepted Answer

Customers may request to perform testing against a dedicated environment, subject to written agreement on scope, timing, and rules of engagement. Secure.com also provides current independent test results as an alternative.

Question 43

Are Secure.com personnel screened?

Accepted Answer

Yes. Background screening is carried out as part of the hiring process and is completed before an individual is engaged. It covers employees, and extends to third parties and contractors where the organisation determines that the nature of their access makes it necessary. Screening is performed to the extent permitted by local law, and where local law restricts a category of check, the restriction and the compensating control applied in its place are recorded rather than left implicit. Screening is one control among several and is not load-bearing on its own. It sits alongside the other personnel controls examined in Secure.com’s SOC 2 Type 2 audit: written employment terms and conditions, a code of conduct, a formal and communicated disciplinary process, performance evaluation, confidentiality obligations, security and privacy awareness training at onboarding and annually, individually attributable identities for employees and contractors alike, and documented offboarding. It also sits alongside the access controls described in Section 3, under which Secure.com personnel hold no standing access to customer data or customer workspaces.

Question 44

What security training do personnel receive?

Accepted Answer

All personnel complete security and privacy awareness training at onboarding, before or alongside being granted access, and repeat it annually thereafter. Reviewing and accepting Secure.com’s security policies is part of the same onboarding step, so that training and policy acknowledgement are completed together rather than separately. Engineering personnel receive additional secure development training covering the controls described in Section 7. Completion is tracked, reported, and reviewed by management, and failure to complete required training is addressed through the disciplinary process.

Question 45

From which countries can personnel access customer data?

Accepted Answer

Secure.com’s operations span the United States, the United Arab Emirates, and Pakistan. Access to customer data from any of these locations is governed by the same controls described in Section 3 and applies without variation by location. Secure.com personnel hold no standing access to customer data or customer workspaces. Where access is required, it is authorised by the customer, requested and approved against a defined purpose, granted for a limited period, exercised under an individually attributable identity, logged, and withdrawn when the purpose is complete. Authentication requires multifactor authentication, and role assignments are reviewed periodically. Customers with restrictions on the geography from which their data may be accessed should raise them during scoping so that they can be addressed in the contract rather than discovered afterwards.

Question 46

How is access removed when personnel leave?

Accepted Answer

Access is revoked as part of a documented offboarding process owned by HR. On termination of employment or engagement, access to all in-scope systems is deprovisioned, and physical and logical access mechanisms — including access cards, keys, and multifactor authentication tokens — are disabled or collected by IT or HR personnel. Access reviews are conducted periodically to confirm that remaining access is appropriate and least-privileged, independently of the offboarding process.

Question 47

How are Secure.com’s own corporate devices secured?

Accepted Answer

Corporate devices are centrally managed and carry endpoint protection software. Device management, patching, and endpoint security are maintained for all personnel with access to production systems or customer data.

Question 48

Does Secure.com use contractors or offshore development?

Accepted Answer

Where contractors are engaged, they are subject to the same screening, training, access control, and confidentiality requirements as employees, and appear in Secure.com’s access records under individually attributable identities.

Question 49

What security certifications does Secure.com hold?

Accepted Answer

Secure.com holds SOC 2 and ISO/IEC 27001 certification. SOC 2 Type 2 ISO/IEC 27001 The report, certificate, and Statement of Applicability are available to qualified customers and prospects through the Trust Center, under NDA where applicable.

Question 50

What is covered by Secure.com’s certified scope?

Accepted Answer

The ISO 27001 Statement of Applicability and the SOC 2 scope statement define the systems, services, and processes covered by each certification. Both are provided alongside the certificate so customers can compare certified scope against the services they are purchasing. The SOC 2 Type 2 examination covers the Secure.com platform and the Amazon Web Services infrastructure supporting it, across all five trust services categories: Security, Availability, Confidentiality, Privacy, and Processing Integrity. The examination addressed the control environment, risk assessment, logical and physical access, change management, system operations, availability and resilience, confidentiality, privacy, and processing integrity, and returned an unqualified opinion with no exceptions noted. Customers evaluating scope should read the SOC 2 scope statement and the ISO 27001 Statement of Applicability alongside the services they are purchasing, and Secure.com will walk through either on request.

Question 51

How does Secure.com classify itself under the EU AI Act?

Accepted Answer

Secure.com’s AI-enabled capabilities are used for cybersecurity operations — detecting, prioritising, investigating, and coordinating response to security issues within a customer’s own environment. They are not used for biometric identification, emotion inference, social scoring, or the other purposes the EU AI Act treats as prohibited, and they do not make decisions about individuals of the kind that attract high-risk classification. On that basis Secure.com’s assessment is that its AI-enabled capabilities are not high-risk systems under the Act. Secure.com keeps that assessment under review as guidance and implementing acts develop. The supply chain matters to this analysis. The foundation models Secure.com uses are accessed through Amazon Bedrock; Secure.com is a deployer of those models rather than the provider of a general-purpose AI model, and the obligations the Act places on model providers rest with the model owners and the service through which they are made available. Secure.com’s own obligations attach to how it builds on and deploys those models. Secure.com maintains documentation of its AI systems, their intended purpose, the models used, and the governance and human-oversight controls applied, and supports customers assessing their own obligations as deployers in their jurisdictions. Under other emerging regimes, including United States federal and state AI requirements, Secure.com takes the same approach: document the system, state the position, and revisit it as the law settles.

Question 52

Does Secure.com offer a Business Associate Agreement?

Accepted Answer

Yes. A mutual Business Associate Agreement is executed on request. Where protected health information could transit the platform, a BAA is required before processing begins. Secure.com’s standard contracting set also includes a Data Processing Agreement, mutual non-disclosure agreement, and service contracts carrying data-protection and confidentiality obligations through to third parties.

Question 53

Who is responsible for responding to a security incident?

Accepted Answer

Responsibility follows the shared responsibility model in the customer agreement. Secure.com is responsible for the security of the Secure.com service and for responding to incidents affecting Secure.com-controlled systems. Customers remain responsible for their own environments, users, configurations, credentials, and connected systems, and for the decisions they authorize, except where a managed service agreement provides otherwise. A full shared responsibility matrix is available through the Trust Center.

Question 54

How quickly does Secure.com notify customers of an incident affecting the platform?

Accepted Answer

Secure.com notifies affected customers without undue delay and in any event no later than 36 hours after determining that an incident has affected their data or service, aligned with the notification timeframe established under the GDPR. Notification sets out what is known at the time, what is being done, and what action the customer should take, and is updated as the investigation progresses rather than withheld until the picture is complete. Where a customer’s own contract or regulatory position requires a shorter notification period, it can be agreed during contracting.

Question 55

What happens if Secure.com identifies a potential incident in a customer environment?

Accepted Answer

Secure.com surfaces, prioritizes, investigates, and coordinates response according to the customer’s configured workflows and subscribed services. The customer determines which notifications, escalations, approvals, and automated actions are permitted.

Question 56

Has Secure.com experienced a security breach?

Accepted Answer

Secure.com has not experienced a breach or data security incident in the preceding thirty-six months.

Question 57

Can customers revoke Secure.com’s access during an incident?

Accepted Answer

Yes. Customers can disable integrations, revoke credentials, restrict permissions, and suspend workflow execution through administrative controls, with immediate effect.

Question 58

What availability does Secure.com commit to?

Accepted Answer

Secure.com commits to 99.89% monthly uptime, as defined in the service level agreement. Historical availability is published on the status page.

Question 59

What are Secure.com’s recovery objectives?

Accepted Answer

Secure.com maintains encrypted backups of production data using cloud-managed backup and recovery mechanisms, with access restricted to authorised personnel. Persistent production data is protected through scheduled backups and versioning where applicable. Business continuity and disaster recovery procedures are periodically tested and reviewed. Recovery Time Objective (RTO): 3 hours Recovery Point Objective (RPO): 12 hours

Question 60

How are customers notified of service interruptions?

Accepted Answer

Material incidents are communicated through the status page, in-product notification, and direct contact with designated customer administrators.

Question 61

Is a public status page available?

Accepted Answer

Yes, at https://www.secure.com/status, showing current availability, active incidents, scheduled maintenance, and historical uptime.

Question 62

What happens if Secure.com becomes unavailable for an extended period?

Accepted Answer

Secure.com maintains documented business continuity procedures. Because Secure.com operates alongside rather than in place of a customer’s underlying security tooling, customers retain access to their source systems during a Secure.com outage, though automated coordination and execution would pause.

Question 63

Does Secure.com use subprocessors?

Accepted Answer

Yes. Amazon Web Services is Secure.com’s subservice organisation for data centre and infrastructure services. AWS provides the compute, container orchestration, networking, load balancing, object storage, managed databases, identity and access management, secrets management, monitoring, audit logging, threat detection, messaging, and — through Amazon Bedrock — the foundation-model inference on which the platform runs. Six complementary subservice organisation controls are relied on at AWS, covering encryption of databases within AWS’s control, restriction of data centre access to authorised personnel, continuous monitoring of data centres by closed-circuit camera and security personnel, secure decommissioning and physical destruction of production assets, fire suppression and environmental monitoring, and protection against disruption to power supply. Secure.com obtains and reviews AWS’s own SOC 2 and related compliance reports annually, and monitors AWS through operational oversight, contract review, and periodic engagement, to confirm that the services provided continue to meet the expected security and availability criteria. Each subprocessor is listed with its purpose, the categories of data it processes, and its processing locations.

Question 64

Where can customers find the subprocessor list?

Accepted Answer

The subprocessor list is published on Secure.com’s privacy policy page at https://www.secure.com/privacy-policy, where it is maintained alongside Secure.com’s other privacy disclosures.

Security, Trust, and AI Governance FAQ

SOC 2 Type 2

ISO/IEC 27001

Data residency

No model training

99.89% uptime

36-hour notification

Frequently Asked Questions

1Data Collection, Processing, and Retention

2Data Residency, Sovereignty, and Deployment

3Tenant Isolation and Access Controls

4AI Model Usage, Privacy, and Isolation

5AI Agent Security

6Human Oversight and Governance

7Security Architecture and Platform Protection

8Personnel and Insider Risk

9Certifications, Assessments, and Compliance

10Incident Response and Responsibility

11Availability, Resilience, and Business Continuity

12Subprocessors and Third Parties

13Privacy and Legal Protections

14Customer Security Responsibilities

15Product Assurance and Responsible AI