NEW

Start with the pressure: sales, launch, abuse, agents, data, or guardrails

aisecurity.llc

Data Processing Addendum

A Data Processing Addendum is available when aisecurity.llc processes personal data on behalf of a customer through the platform, professional services, training, integrations, evidence handling, or customer-configured workflows. This page explains when a DPA is needed, what it covers, and how it relates to our Privacy Policy, Subprocessors, Evidence Handling Policy, and SOWs.

Procurement summaryPublic policy summary

A DPA is used when customer personal data is processed on behalf of a customer. Not every scoping conversation requires a DPA. High-level business contact information and non-sensitive scoping usually do not require a full DPA. Customer data, personal data, regulated data, identity data, logs, screenshots, or evidence may require DPA or SOW-specific terms. Customers should avoid sending personal data or regulated data through public forms. DPA terms may be included in or attached to a private offer, SOW, or enterprise agreement.

1. Plain-English Summary

  • A DPA is used when customer personal data is processed on behalf of a customer.
  • Not every scoping conversation requires a DPA.
  • High-level business contact information and non-sensitive scoping usually do not require a full DPA.
  • Customer data, personal data, regulated data, identity data, logs, screenshots, or evidence may require DPA or SOW-specific terms.
  • Customers should avoid sending personal data or regulated data through public forms.
  • DPA terms may be included in or attached to a private offer, SOW, or enterprise agreement.

2. When a DPA Is Needed

A DPA is typically needed when:

  • Customer personal data is processed in a workspace or platform feature.
  • Service evidence includes personal data.
  • Logs, traces, screenshots, prompts, or artifacts contain personal data.
  • LMS or training records are processed for customer users.
  • SSO, SAML, OIDC, SCIM, or provisioning data is processed.
  • Integrations process employee, customer, or user identity data.
  • SecEng Copilot or AI-assisted workflows process personal data under customer instruction.
  • Professional services require customer or customer-user personal data.
  • A customer's procurement or legal process requires one.

A DPA is not usually needed for:

  • Browsing public pages.
  • Public research or library pages.
  • Basic contact forms using business contact details.
  • High-level, non-sensitive scoping.
  • Public target information.
  • Anonymized or aggregated discussions.
  • General sales conversations with no customer personal data.

3. Processing Roles

  • The customer is usually controller or business for customer personal data it provides.
  • aisecurity.llc may act as processor or service provider for customer personal data processed through platform or services.
  • aisecurity.llc may act as independent controller for its own business operations, billing, security, fraud and abuse prevention, and marketing or admin data.
  • Exact roles may be defined in the DPA, SOW, order form, or enterprise agreement.

4. Categories of Personal Data

  • Business contact data.
  • Account and user profile data.
  • Organization and workspace membership.
  • Role, entitlement, and seat data.
  • SSO, SAML, OIDC, and SCIM identity and provisioning data.
  • LMS and training enrollment and progress data.
  • Support communications.
  • Scoping and intake data.
  • Uploaded artifacts and evidence where they contain personal data.
  • Logs, traces, prompts, screenshots, or reports where they contain personal data.
  • SecEng Copilot or chat content where it contains personal data.
  • Integration metadata.
  • Billing metadata.

5. Processing Purposes

  • Provide website, platform, and services.
  • Manage accounts, organizations, seats, roles, and entitlements.
  • Perform scoping and packet generation.
  • Deliver AI Launch, pentest/red-team, product security, governance, training, and related services.
  • Provide SecEng Copilot and AI-assisted workflows where enabled.
  • Support integrations and connectors.
  • Provide LMS and training access.
  • Generate reports, evidence packets, and due-diligence artifacts.
  • Process private offers, SOWs, NDAs, DPAs, ROEs, and procurement workflows.
  • Provide support.
  • Secure the platform.
  • Prevent abuse.
  • Process billing and subscriptions.
  • Comply with legal obligations.

6. Subprocessors

See the Subprocessors page for the current public list.

  • Subprocessors may include core platform providers, AI model providers, payment processors, communications providers, analytics or diagnostics providers, and customer-configured integrations.
  • Not every subprocessor is used for every customer.
  • Customer-configured integrations are enabled by the customer or admin and may involve third-party terms.
  • Enterprise agreements may define subprocessor notification or objection rights.

7. AI and Model Training

  • Customer data is not used to train public AI models.
  • aisecurity.llc does not authorize third-party model providers to train on customer content submitted through approved service or platform pathways.
  • AI providers may process inputs and outputs to provide enabled features.
  • AI processing may vary by feature, configuration, and agreement.
  • Customers may request AI-free or restricted processing for certain professional services where available and agreed in writing.
  • DPA or SOW terms may specify AI handling instructions.

8. Security Measures

  • Access controls.
  • Least privilege.
  • Workspace and organization separation.
  • Encryption in transit.
  • Encryption at rest where supported by infrastructure providers.
  • Evidence handling and minimization.
  • Redaction defaults.
  • Approved intake channels.
  • Logging and monitoring where appropriate.
  • Vulnerability management.
  • Subprocessor and vendor review.
  • Incident response process.

See the Security Practices and Evidence Handling Policy pages for the operational summary.

9. International Transfers

Processing may involve providers or infrastructure outside the customer's jurisdiction. Where required, transfer mechanisms may include SCCs, DPA terms, provider safeguards, or other lawful mechanisms. Exact transfer terms may be defined in the DPA or enterprise agreement.

10. Deletion and Return

  • Return or deletion is handled according to the DPA, SOW, Retention & Redaction Policy, and legal obligations.
  • Customers may request deletion or export where supported.
  • Some records may be retained for billing, legal, security, audit, or fraud-prevention obligations.
  • Backups and logs may have limited residual retention.
  • Evidence artifacts may have engagement-specific retention rules.

11. Security Incident / Breach Assistance

  • Notice and cooperation are defined in the DPA or SOW.
  • Customers should provide a security contact.
  • Incident handling depends on the nature of the data, service, and agreement.
  • Vulnerability reports follow the Vulnerability Disclosure Policy.

12. Data Subject Requests

  • The customer is usually responsible for responding to requests about customer personal data.
  • aisecurity.llc will provide reasonable assistance as defined in the DPA or SOW.
  • Requests related to aisecurity.llc-controlled account or business data may be handled under the Privacy Policy.

13. How to Request a DPA

Tell us:

  • Organization name.
  • Services or products in scope.
  • Jurisdiction or region needs.
  • Data categories.
  • Whether customer, personal, or regulated data will be processed.
  • Whether AI-assisted processing is allowed or restricted.
  • Preferred agreement path.

Data Processing Addendum (Public Summary) · aisecurity.llc · Effective June 27, 2026 · Version 1.0

← Back to Legal