Data Processing Addendum

This Data Processing Addendum template is intended to supplement the wrxstack Terms of Service when an enterprise customer acts as controller and wrxstack acts as processor for customer personal data.

This draft is not a signed agreement, legal advice, or a substitute for counsel review. It should be finalized with the customer name, legal entity, governing law, subprocessors, transfer mechanism, and signed order form before enterprise use.

• Template owner: Farhan.
• Review state: draft pending owner and counsel sign-off.
• Intended pairing: Terms of Service, Privacy Policy, enterprise order form, and final processor list.

For customer personal data submitted to the service by or for an enterprise tenant, the customer is the controller and wrxstack is the processor unless a final signed agreement says otherwise.

The processor processes customer personal data only to provide, secure, support, monitor, troubleshoot, and improve the contracted portfolio service, and only according to documented customer instructions in the agreement and product controls.

• Controller: the enterprise tenant or legal entity that determines the purpose and means of processing.
• Processor: wrxstack, operating the portfolio platform and supporting infrastructure.
• Customer personal data includes account, tenant, portfolio, upload, contact, support, security, usage, and AI-generation data submitted through the service.

The subject matter, duration, nature, purpose, categories of data, and categories of data subjects should be finalized in the schedules before signature.

• Subject matter: hosting, editing, generating, publishing, exporting, securing, and supporting professional portfolio content.
• Duration: the subscription term plus deletion, backup, legal, security, and audit retention periods described in the final agreement.
• Nature and purpose: account administration, portfolio publication, AI-assisted drafting, media processing, email delivery, custom-domain routing, PDF export, support, security, observability, incident response, and compliance operations.
• Data subjects: tenant users, portfolio owners, invited members, portfolio visitors who contact a tenant, and people referenced in customer-provided content.
• Data categories: identifiers, contact details, account security data, portfolio content, uploaded media and documents, support messages, usage data, audit events, request metadata, and delivery status.

wrxstack should process customer personal data only on documented instructions from the customer, including instructions reflected in product configuration, tenant role assignments, admin actions, support requests, and the final agreement.

If an instruction appears unlawful or would create an unsafe security or operational condition, the processor should notify the customer unless legally prohibited.

• Product instructions include publish/unpublish, edit, delete, upload, custom-domain, AI generation, PDF export, account deletion, and access-control actions.
• The service should not use customer personal data for unrelated advertising or to train wrxstack-owned models.
• Support access and super-admin actions should stay purpose-bound, audited, and limited to authorized operators.

Personnel and contractors authorized to process customer personal data should be bound by confidentiality obligations or equivalent professional duties.

Access should be limited to people who need it to operate, secure, support, or improve the service, and privileged access should be governed by elevated-session and audit controls.

• Customer secrets, private drafts, raw prompts, raw resumes, and uploaded documents should not be copied into logs or public evidence.
• Incident, support, and privacy request handling should use request IDs, tenant IDs, account emails, or public URLs where possible instead of raw sensitive content.

The final DPA should attach technical and organizational measures appropriate to the risk of the processing. The current product controls are source-backed in the build plan and release gates.

• Authentication controls include secure sessions, email verification, password reset flows, passkeys, TOTP, Altcha proof-of-work protection, rate limits, and session revocation.
• Tenant isolation uses tenant-scoped data access, route guards, role checks, and lint rules that block unscoped Prisma access patterns.
• Operational controls include structured logging, PII redaction, request IDs, OpenTelemetry spans, GlitchTip capture, Uptime Kuma status monitoring, incident response drills, backup/restore drills, audit logs, checksum jobs, and source-safe evidence rules.
• Infrastructure controls include Render hosting, managed Postgres, Cloudflare DNS/CDN/WAF/storage, AWS SES email delivery, R2 object storage, Caddy ASK domain validation, and fail-closed health/security checks.

wrxstack uses subprocessors only as needed to provide, secure, monitor, support, and improve the service. The final agreement should include a current subprocessor list and a notice process for material additions or replacements.

• Render: application hosting, managed Postgres, supporting services, scheduled jobs, and deployment runtime.
• Cloudflare: DNS, CDN, WAF, custom-domain routing, and object storage where configured.
• AWS SES: service email delivery and email delivery status processing.
• Anthropic: optional AI generation when a user invokes AI-assisted drafting.
• GlitchTip and Uptime Kuma: error tracking, uptime monitoring, and incident visibility.
• Optional analytics tooling should remain disabled or documented before enterprise launch.

The service may be operated from the United States and may use providers that process personal data in the United States or other countries. The final DPA must identify the transfer mechanism that applies for each enterprise customer.

Where EU, UK, Swiss, or other restricted-transfer rules apply, the final agreement should attach appropriate standard contractual clauses, UK addendum or IDTA terms, supplementary measures, and subprocessor transfer details as counsel requires.

• This template does not claim certification under a specific transfer framework.
• Transfer safeguards should be reviewed against the customer jurisdiction, provider locations, data categories, and customer instructions before signature.

wrxstack should assist the customer with reasonable data subject requests when the customer cannot fulfill the request through product controls, taking into account the nature of processing and available information.

• Product controls may support editing, export, deletion, publication changes, account deletion, and access revocation.
• Requests should be verified to avoid unauthorized disclosure, deletion, or tenant takeover.
• The processor should not respond directly to data subjects as controller for customer personal data unless the customer instructs it or law requires it.

The final DPA should define personal data breach and security incident notification obligations, including timing, contact paths, evidence handling, and any exceptions for unsuccessful or low-risk attempts.

The current incident-response gate covers production down, recent bad deploy, degraded dependency, single-tenant critical issue, and audit-integrity alert scenarios with source-safe evidence and status communication steps.

• Notify the customer without undue delay after confirming a personal data breach affecting customer personal data, subject to legal and security constraints.
• Provide source-safe information reasonably available, such as incident dates, affected systems, likely impact, mitigation, and remediation status.
• Do not disclose secrets, raw logs, or third-party customer data in public incident updates.

wrxstack should provide reasonable information needed to demonstrate compliance with the final DPA, including security documentation, audit evidence, and release-gate results, subject to confidentiality and security limits.

On-site or intrusive audits should be pre-agreed, scoped, time-bounded, and structured to avoid disrupting the service or exposing other tenants.

• Available evidence may include legal docs audit, backup restore audit, incident response drill, browser/mobile/a11y gates, security Semgrep contracts, super-admin penetration checklist, and status-page evidence.
• Customer audit requests should not require raw database exports, private keys, provider credentials, or other tenants personal data.

At termination or on verified customer request, wrxstack should delete or return customer personal data according to the final agreement, product controls, and operational retention limits.

Backups, audit records, security logs, incident evidence, and legal records may remain for limited periods where needed for security, compliance, dispute resolution, integrity, or recovery.

• Account deletion and tenant deletion workflows should remove active product data subject to backup and legal limits.
• Backup deletion should follow backup lifecycle and retention procedures rather than record-by-record mutation.
• Deletion evidence should remain source-safe and should not include raw customer content.

The final DPA should define how it interacts with the Terms, Privacy Policy, order form, security exhibit, standard contractual clauses, and any customer-specific amendments.

If a conflict exists between the DPA and another agreement, counsel should decide the priority order before signature. Standard contractual clauses or mandatory law may override conflicting commercial terms where applicable.

Before enterprise signature, the parties should complete the schedules with customer-specific processing details, subprocessor list, security measures, transfer terms, contacts, notification windows, and deletion timelines.

• Schedule 1: subject matter, duration, nature, purpose, data categories, data subjects, sensitive data, processing frequency, and retention.
• Schedule 2: approved subprocessors, service description, processing location, transfer mechanism, and notice period.
• Schedule 3: technical and organizational measures, including tenant isolation, encryption, authentication, access controls, logging, backup, incident response, vulnerability management, and business continuity.
• Schedule 4: international transfer module, SCC or UK addendum details, supplementary measures, and customer export instructions.

Questions, procurement comments, privacy team review notes, and legal-signoff comments should be sent to contactmdfarhankhan@gmail.com. Include the relevant customer name, tenant slug, account email, request ID, or custom domain when available.

This template should not be published as a final enterprise DPA until the owner and qualified counsel approve the complete document and schedules.