Unclassified
IntegrateWise Security & Compliance Pack
Security Whitepaper & Compliance Documentation
Version: 1.0
Classification: Public
Last Updated: January 2026
Audience: Procurement, IT Security, Compliance Teams
Table of Contents
- Executive Summary
- Security Architecture
- Data Security
- Data Residency
- Encryption Policies
- Access Controls & Roles
- Authentication & Identity
- Third-Party Vendors
- Backup & Disaster Recovery
- Incident Response
- Audit Logging
- Log Retention
- Compliance Status
- Security Questionnaire
1. Executive Summary
1.1 Security Commitment
IntegrateWise is built with security as a foundational principle. We understand that our customers trust us with their most sensitive business data, and we take that responsibility seriously.
Core Security Principles:
| Principle | Implementation |
|---|---|
| Defense in Depth | Multiple layers of security controls |
| Least Privilege | Minimum access required for function |
| Zero Trust | Verify all requests, trust nothing by default |
| Encryption Everywhere | Data encrypted at rest and in transit |
| Transparency | Clear audit trails and logging |
| User Control | You own your data, always |
1.2 Security Highlights
| Feature | Status |
|---|---|
| Data Encryption (Transit) | ✅ TLS 1.3 |
| Data Encryption (Rest) | ✅ AES-256 |
| Multi-Tenant Isolation | ✅ Row-Level Security |
| MFA Support | ✅ TOTP-based |
| SSO/SAML | ✅ Enterprise plan |
| SOC 2 Type II | 🔄 In progress (Q2 2026) |
| GDPR Compliant | ✅ |
| Data Export | ✅ On-demand |
| Data Deletion | ✅ Within 30 days |
1.3 You Own Your Data
IntegrateWise operates on a fundamental principle: your data belongs to you.
- No data selling: We never sell, rent, or share your data
- No AI training: Your data is never used to train AI models
- Full portability: Export all your data anytime
- Complete deletion: Request deletion and we remove everything
- Transparent processing: We only process data as you direct
2. Security Architecture
2.1 Infrastructure Security
┌─────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ARCHITECTURE │
└─────────────────────────────────────────────────────────────────────────────┘
INTERNET
│
┌────────────┴────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ DDoS Mitigation│ │ Bot Detection │
│ (Cloudflare) │ │ (Cloudflare) │
└────────┬────────┘ └────────┬────────┘
│ │
└───────────┬─────────────┘
│
▼
┌─────────────────────┐
│ Web Application │
│ Firewall (WAF) │
│ • OWASP Top 10 │
│ • Rate Limiting │
│ • IP Reputation │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ TLS Termination │
│ • TLS 1.3 only │
│ • HSTS enabled │
│ • Certificate pin │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ API Authentication │
│ • JWT validation │
│ • API key verify │
│ • Session check │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Authorization │
│ • RBAC check │
│ • Scope verify │
│ • Tenant isolate │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Data Layer │
│ • RLS policies │
│ • Encrypted data │
│ • Audit logging │
└─────────────────────┘
2.2 Network Security
| Control | Implementation |
|---|---|
| DDoS Protection | Cloudflare (automatic, always-on) |
| WAF | Cloudflare WAF with custom rules |
| Rate Limiting | Per-endpoint, per-tenant limits |
| IP Allowlisting | Optional for enterprise customers |
| TLS Version | TLS 1.3 required (1.2 minimum) |
| Certificate | Managed, auto-renewed |
2.3 Application Security
| Control | Implementation |
|---|---|
| Input Validation | Zod schema validation on all inputs |
| Output Encoding | Context-aware encoding |
| SQL Injection | Parameterized queries (Prisma ORM) |
| XSS Prevention | React auto-escaping + CSP headers |
| CSRF Protection | SameSite cookies + tokens |
| Dependency Scanning | Automated (Dependabot, Snyk) |
| Code Review | Required for all changes |
3. Data Security
3.1 Data Classification
| Classification | Description | Examples | Controls |
|---|---|---|---|
| Public | Non-sensitive | Marketing materials | Basic |
| Internal | Business data | Account names, emails | Encrypted, access-controlled |
| Confidential | Sensitive business | Revenue, health scores | Encrypted, audit logged |
| Restricted | Highly sensitive | API keys, tokens | Encrypted, minimal access |
3.2 Data Flow Security
┌─────────────────────────────────────────────────────────────────────────────┐
│ DATA FLOW SECURITY │
└─────────────────────────────────────────────────────────────────────────────┘
External Tool IntegrateWise User
(e.g., HubSpot)
│ │ │
│ TLS 1.3 encrypted │ │
├───────────────────────────▶│ │
│ │ │
│ ┌──────┴──────┐ │
│ │ API Gateway │ │
│ │ (Edge) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Transform │ │
│ │ & Validate │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Encrypt at │ │
│ │ Rest (AES) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ PostgreSQL │ │
│ │ (Supabase) │ │
│ └──────┬──────┘ │
│ │ │
│ │ TLS 1.3 encrypted │
│ ├───────────────────────────▶│
│ │ │
3.3 Data Isolation
Multi-Tenant Architecture:
Every customer's data is logically isolated using PostgreSQL Row-Level Security (RLS):
-- All tables include organization_id
-- RLS policies enforce tenant isolation
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON accounts
FOR ALL
USING (organization_id = current_setting('app.organization_id')::UUID);
-- Customer A can NEVER access Customer B's data
-- Even if SQL injection occurred, RLS prevents cross-tenant access
| Isolation Method | Implementation |
|---|---|
| Database | Row-Level Security (RLS) |
| Application | Tenant context in every request |
| Storage | Prefixed by organization ID |
| Cache | Tenant-scoped keys |
| Logs | Filtered by organization |
4. Data Residency
4.1 Primary Data Locations
| Data Type | Location | Provider | Region |
|---|---|---|---|
| Primary Database | AWS | Supabase | us-east-1 (N. Virginia) |
| Database Backups | AWS | Supabase | us-east-1 |
| File Storage | Cloudflare | R2 | Global (edge-cached) |
| Edge Cache | Cloudflare | KV | Global (300+ PoPs) |
| Application | Cloudflare | Workers | Global (edge) |
4.2 Data Residency Statement
Current Status:
- Primary data storage is in United States (AWS us-east-1)
- Edge caching occurs globally but is temporary (< 60 minutes)
- Backups remain in the same region as primary data
EU Data Residency (Roadmap Q4 2026):
- Dedicated EU region option (AWS eu-west-1)
- EU-only data processing
- Data sovereignty compliance
4.3 Cross-Border Data Transfers
For customers outside the United States:
| Mechanism | Status |
|---|---|
| Standard Contractual Clauses (SCCs) | Available on request |
| Data Processing Agreement (DPA) | Included in Enterprise contracts |
| EU-US Data Privacy Framework | Pending (vendors in progress) |
5. Encryption Policies
5.1 Encryption Overview
| State | Method | Key Size | Details |
|---|---|---|---|
| In Transit | TLS 1.3 | 256-bit | All connections |
| At Rest (Database) | AES-256 | 256-bit | Supabase managed |
| At Rest (Files) | AES-256 | 256-bit | Cloudflare R2 |
| At Rest (Backups) | AES-256 | 256-bit | Encrypted snapshots |
| Secrets | AES-256-GCM | 256-bit | Cloudflare Workers secrets |
5.2 Encryption in Transit
┌─────────────────────────────────────────────────────────────────────────────┐
│ ENCRYPTION IN TRANSIT │
└─────────────────────────────────────────────────────────────────────────────┘
User Browser API Gateway Database
│ │ │
│ TLS 1.3 │ │
│ ────────────────────▶ │ │
│ • ECDHE key exchange │ │
│ • AES-256-GCM cipher │ │
│ • Perfect Forward Sec │ │
│ │ │
│ │ TLS 1.3 │
│ │ ─────────────────────────▶ │
│ │ • Mutual TLS (mTLS) │
│ │ • Certificate pinning │
│ │ │
TLS Configuration:
- Minimum version: TLS 1.2 (TLS 1.3 preferred)
- Cipher suites: Modern, AEAD-only
- HSTS: Enabled (max-age=31536000)
- Certificate: 2048-bit RSA, auto-renewed
5.3 Encryption at Rest
Database Encryption:
┌─────────────────────────────────────────────────────────────────────────────┐
│ DATABASE ENCRYPTION │
└─────────────────────────────────────────────────────────────────────────────┘
Application Supabase AWS KMS
│ │ │
│ Plaintext data │ │
│ ─────────────────────▶ │ │
│ │ │
│ │ Request DEK │
│ │ ─────────────────────────▶ │
│ │ │
│ │ DEK (encrypted with CMK) │
│ │ ◀───────────────────────── │
│ │ │
│ ┌──────┴──────┐ │
│ │ Encrypt │ │
│ │ with DEK │ │
│ │ (AES-256) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Store │ │
│ │ encrypted │ │
│ │ on disk │ │
│ └─────────────┘ │
Key Management:
- Customer Master Keys (CMK): AWS KMS managed
- Data Encryption Keys (DEK): Rotated automatically
- Key access: Logged and audited
- No customer access to encryption keys (managed service)
5.4 Sensitive Field Encryption
Additional encryption for highly sensitive fields:
| Field | Encryption | Notes |
|---|---|---|
| OAuth Tokens | AES-256-GCM | Application-level encryption |
| API Keys | Hashed (bcrypt) | One-way hash, cannot be decrypted |
| Webhook Secrets | AES-256-GCM | Application-level encryption |
6. Access Controls & Roles
6.1 Role-Based Access Control (RBAC)
IntegrateWise implements RBAC with four standard roles:
| Role | Description | Permissions |
|---|---|---|
| Admin | Full access | All permissions including user management |
| Manager | Team lead access | Read/write + cross-team visibility |
| Member | Standard user | Read/write within assigned team |
| Viewer | Read-only | View dashboards and reports only |
6.2 Permission Matrix
| Permission | Admin | Manager | Member | Viewer |
|---|---|---|---|---|
| View accounts | ✅ | ✅ | ✅ | ✅ |
| Edit accounts | ✅ | ✅ | ✅ | ❌ |
| Delete accounts | ✅ | ✅ | ❌ | ❌ |
| View all teams | ✅ | ✅ | ❌ | ❌ |
| Manage users | ✅ | ❌ | ❌ | ❌ |
| API key management | ✅ | ❌ | ❌ | ❌ |
| Integration setup | ✅ | ✅ | ❌ | ❌ |
| Automation create | ✅ | ✅ | ✅ | ❌ |
| Automation approve | ✅ | ✅ | ❌ | ❌ |
| View audit logs | ✅ | ✅ | ❌ | ❌ |
| Export data | ✅ | ✅ | ❌ | ❌ |
6.3 Hub-Based Access Control
In addition to roles, access is controlled by Hub (team/function) membership:
┌─────────────────────────────────────────────────────────────────────────────┐
│ HUB-BASED ACCESS CONTROL │
└─────────────────────────────────────────────────────────────────────────────┘
User: jane@company.com
Role: Member
Hubs: [Sales, Customer Success]
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Sales │ │ CS │ │ Finance │
│ Hub │ │ Hub │ │ Hub │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ • Deals │ │ • Health │ │ • Invoices │
│ • Pipeline │ │ • Renewals │ │ • Revenue │
│ • Leads │ │ • Tickets │ │ • Billing │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
✅ Access ✅ Access ❌ No Access
6.4 SOC 2 Control Mapping
| SOC 2 Control | IntegrateWise Implementation |
|---|---|
| CC6.1 - Logical access | RBAC + Hub-based access |
| CC6.2 - Prior authorization | Role assignment requires Admin |
| CC6.3 - Access removal | Immediate on user deactivation |
| CC6.6 - Access review | Quarterly access review (Admin tool) |
| CC6.7 - User responsibilities | Security policy acceptance |
7. Authentication & Identity
7.1 Authentication Methods
| Method | Availability | Details |
|---|---|---|
| Email + Password | All plans | Minimum 12 characters, complexity required |
| Magic Link | All plans | Passwordless email authentication |
| Google SSO | All plans | OAuth 2.0 |
| Microsoft SSO | Pro+ plans | OAuth 2.0 / Azure AD |
| SAML 2.0 | Enterprise | Custom IdP integration |
| MFA (TOTP) | All plans | Google Authenticator, Authy, etc. |
7.2 Password Policy
| Requirement | Value |
|---|---|
| Minimum length | 12 characters |
| Complexity | Upper, lower, number, symbol |
| History | Last 5 passwords blocked |
| Expiration | Optional (90 days recommended) |
| Lockout | 5 failed attempts → 15 min lockout |
7.3 Session Management
| Setting | Value |
|---|---|
| Session timeout (web) | 24 hours |
| Session timeout (API) | No expiration (API key) |
| Concurrent sessions | Unlimited (configurable) |
| Session invalidation | Immediate on logout/password change |
| Refresh token | 7 days |
7.4 MFA Implementation
┌─────────────────────────────────────────────────────────────────────────────┐
│ MFA AUTHENTICATION FLOW │
└─────────────────────────────────────────────────────────────────────────────┘
User IntegrateWise TOTP App
│ │ │
│ 1. Email + Password │ │
│ ───────────────────────▶ │ │
│ │ │
│ 2. "Enter MFA code" │ │
│ ◀─────────────────────── │ │
│ │ │
│ │ │
│ 3. Get code │ │
│ ──────────────────────────────────────────────────────▶ │
│ │ │
│ 4. 6-digit code │ │
│ ◀────────────────────────────────────────────────────── │
│ │ │
│ 5. Submit code │ │
│ ───────────────────────▶ │ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Verify TOTP │ │
│ │ (30s window)│ │
│ └──────┬──────┘ │
│ │ │
│ 6. Access granted │ │
│ ◀─────────────────────── │ │
7.5 Enterprise SSO (SAML)
For Enterprise customers:
| Feature | Support |
|---|---|
| IdP Support | Okta, Azure AD, OneLogin, PingFederate, custom |
| Just-In-Time (JIT) | User auto-provisioning on first login |
| Group Mapping | IdP groups → IntegrateWise roles |
| Forced SSO | Disable password auth for org |
| SCIM | Coming Q3 2026 |
8. Third-Party Vendors
8.1 Sub-Processors List
| Vendor | Purpose | Data Processed | Location | Certifications |
|---|---|---|---|---|
| Cloudflare | CDN, Edge compute, WAF | All traffic, cached content | Global | SOC 2, ISO 27001 |
| Supabase | Database, Auth | All customer data | US (AWS) | SOC 2 |
| AWS | Infrastructure (via Supabase) | Database storage | us-east-1 | SOC 2, ISO 27001, FedRAMP |
| OpenAI | AI completions | Prompts, responses | US | SOC 2 |
| Anthropic | AI completions | Prompts, responses | US | SOC 2 |
| n8n Cloud | Workflow automation | Workflow data | EU/US | SOC 2 in progress |
8.2 Vendor Security Requirements
All vendors must meet:
- SOC 2 Type II certification (or equivalent)
- Encryption at rest and in transit
- Access controls and audit logging
- Incident notification within 72 hours
- Annual security review
8.3 AI Data Processing
OpenAI / Anthropic:
| Concern | Policy |
|---|---|
| Data retention | Not retained after response |
| Model training | Your data is NOT used for training |
| API security | TLS encryption, API key auth |
| Data minimization | Only necessary context sent |
We use the API versions of these services, not the consumer products. API terms explicitly prohibit using customer data for model training.
9. Backup & Disaster Recovery
9.1 Backup Strategy
| Backup Type | Frequency | Retention | Location |
|---|---|---|---|
| Full database | Daily | 30 days | Same region |
| Point-in-time | Continuous | 7 days | Same region |
| Transaction logs | Continuous | 7 days | Same region |
| File storage | Replicated | 30 days | Multi-region |
9.2 Recovery Objectives
| Metric | Target | Tested |
|---|---|---|
| RTO (Recovery Time Objective) | 4 hours | Quarterly |
| RPO (Recovery Point Objective) | 1 hour | Quarterly |
| Backup verification | Weekly | Automated |
9.3 Disaster Recovery Plan
┌─────────────────────────────────────────────────────────────────────────────┐
│ DISASTER RECOVERY TIERS │
└─────────────────────────────────────────────────────────────────────────────┘
Tier 1: Application failure (single component)
──────────────────────────────────────────────
Response: Automatic failover (< 1 minute)
• Cloudflare Workers: Auto-restart
• Supabase: Connection retry
• n8n: Job retry queue
Tier 2: Database failure
────────────────────────
Response: Failover to replica (< 15 minutes)
• Automatic failover to hot standby
• DNS update propagation
• Application reconnection
Tier 3: Region failure (AWS us-east-1)
──────────────────────────────────────
Response: Manual failover (< 4 hours)
• Restore from backup to alternate region
• Update DNS records
• Notify customers
Tier 4: Complete infrastructure failure
───────────────────────────────────────
Response: Rebuild from backups (< 24 hours)
• Restore database from off-site backup
• Redeploy application from source control
• Regenerate secrets (customer action required)
9.4 Data Recovery for Customers
| Request Type | SLA | Process |
|---|---|---|
| Accidental deletion (< 24 hours) | 4 hours | Support request |
| Historical data recovery | 24-48 hours | Support request |
| Point-in-time recovery | 24 hours | Enterprise only |
10. Incident Response
10.1 Incident Classification
| Severity | Definition | Response Time | Notification |
|---|---|---|---|
| Critical (P1) | Service unavailable, data breach | 15 minutes | Immediate |
| High (P2) | Major feature unavailable | 1 hour | Within 4 hours |
| Medium (P3) | Minor feature issue | 4 hours | Within 24 hours |
| Low (P4) | Cosmetic, minor bugs | Next business day | None |
10.2 Incident Response Process
┌─────────────────────────────────────────────────────────────────────────────┐
│ INCIDENT RESPONSE FLOW │
└─────────────────────────────────────────────────────────────────────────────┘
1. DETECTION 2. TRIAGE 3. CONTAINMENT
───────────── ───────── ─────────────
• Monitoring alerts • Assess severity • Isolate affected
• Customer report • Assign incident lead • Stop bleeding
• Security scanner • Open incident channel • Preserve evidence
│ │ │
▼ ▼ ▼
4. INVESTIGATION 5. REMEDIATION 6. RECOVERY
──────────────── ───────────── ──────────
• Root cause analysis • Deploy fix • Restore service
• Timeline reconstruction • Patch vulnerability • Verify integrity
• Scope determination • Update defenses • Monitor closely
│ │ │
└──────────────────────────────┴──────────────────────────────┘
│
▼
7. POST-INCIDENT
─────────────────
• Incident report (within 72 hours)
• Lessons learned
• Process improvements
• Customer communication (if applicable)
10.3 Security Incident Communication
Customer Notification Timeline:
| Event | Notification |
|---|---|
| Security incident detected | Status page update within 1 hour |
| Customer data potentially affected | Direct email within 24 hours |
| Incident contained | Status page update |
| Root cause determined | Detailed report within 72 hours |
| Remediation complete | Final report within 7 days |
10.4 Contact for Security Issues
Security Team Contact:
- Email: security@integratewise.com
- Response SLA: 24 hours for non-critical, 4 hours for critical
Vulnerability Disclosure:
- Email: security@integratewise.com
- Subject: "Responsible Disclosure: [Brief Description]"
- We do not currently have a bug bounty program
11. Audit Logging
11.1 What We Log
| Event Category | Events Logged | Retention |
|---|---|---|
| Authentication | Login, logout, MFA, password change | 2 years |
| Authorization | Permission changes, role changes | 2 years |
| Data Access | Read, create, update, delete | 1 year |
| Administrative | User management, settings changes | 2 years |
| Integration | Connection, sync, disconnect | 1 year |
| Security | Failed logins, blocked requests | 2 years |
11.2 Audit Log Format
{
"id": "log_a1b2c3d4e5f6",
"timestamp": "2026-01-07T10:30:00.000Z",
"organization_id": "org_xyz789",
"user_id": "usr_abc123",
"user_email": "jane@company.com",
"action": "account.update",
"resource_type": "account",
"resource_id": "acc_def456",
"changes": {
"health_score": {
"from": 72,
"to": 45
}
},
"ip_address": "192.168.1.1",
"user_agent": "Mozilla/5.0...",
"request_id": "req_ghi789"
}
11.3 Accessing Audit Logs
In Application:
- Settings → Audit Logs (Admin role required)
- Filter by user, action, date range
- Export to CSV
Via API:
GET /v1/audit-logs?start_date=2026-01-01&end_date=2026-01-07&action=account.*
12. Log Retention
12.1 Retention Policies
| Log Type | Retention | Storage | Deletion |
|---|---|---|---|
| Audit logs | 2 years | PostgreSQL | Automatic |
| Application logs | 30 days | Cloudflare | Automatic |
| Security logs | 2 years | PostgreSQL | Automatic |
| Access logs | 90 days | Cloudflare | Automatic |
| Error logs | 90 days | External service | Automatic |
12.2 Customer Data Retention
| Data Type | Active Account | After Account Closure |
|---|---|---|
| Business data | Retained | 30 days then deleted |
| Audit logs | 2 years | 30 days then deleted |
| Backups | 30 days rolling | Purged within 30 days |
| Files/attachments | Retained | 30 days then deleted |
12.3 Data Deletion Process
Upon account closure or deletion request:
- Immediate: Disable access, mark for deletion
- Within 7 days: Remove from active database
- Within 30 days: Purge from backups
- Confirmation: Email confirmation of deletion
13. Compliance Status
13.1 Current Certifications
| Framework | Status | Timeline |
|---|---|---|
| SOC 2 Type I | In progress | Q1 2026 |
| SOC 2 Type II | Planned | Q2 2026 |
| ISO 27001 | Roadmap | 2027 |
| HIPAA | Roadmap | 2027 |
| GDPR | ✅ Compliant | - |
| CCPA | ✅ Compliant | - |
13.2 GDPR Compliance
| GDPR Right | Implementation |
|---|---|
| Right to Access | Data export feature (Settings → Export) |
| Right to Rectification | Edit any record in app |
| Right to Erasure | Account deletion (30-day process) |
| Right to Portability | Export in standard formats (JSON, CSV) |
| Right to Object | Contact support to object to processing |
| Data Minimization | Only collect necessary data |
Data Processing Agreement (DPA): Available upon request for customers who require it.
13.3 SOC 2 Trust Service Criteria
| Criteria | Controls in Place |
|---|---|
| Security | WAF, encryption, access controls, MFA |
| Availability | 99.9% SLA, DR plan, monitoring |
| Processing Integrity | Input validation, audit logs, testing |
| Confidentiality | Encryption, access controls, NDA |
| Privacy | GDPR compliance, data minimization |
14. Security Questionnaire
14.1 Common Questions
Infrastructure
Q: Where is data stored?
A: Primary data is stored in AWS us-east-1 (N. Virginia) via Supabase. Edge caching uses Cloudflare's global network.
Q: Is data encrypted?
A: Yes. TLS 1.3 in transit, AES-256 at rest.
Q: Do you have a SOC 2 report?
A: SOC 2 Type II is in progress (expected Q2 2026). Contact security@integratewise.com for current status.
Access Control
Q: How is access controlled?
A: Role-based access control (RBAC) with four roles. Additional Hub-based access for team isolation.
Q: Do you support SSO?
A: Yes. Google and Microsoft OAuth for all plans. SAML 2.0 for Enterprise.
Q: Is MFA supported?
A: Yes. TOTP-based MFA available for all users.
Data Handling
Q: Can I export my data?
A: Yes. Full export available in JSON and CSV formats from Settings → Export.
Q: What happens when I close my account?
A: All data is deleted within 30 days, including backups.
Q: Is my data used for AI training?
A: No. Your data is never used for AI model training. We use API versions of OpenAI/Anthropic which prohibit training on customer data.
Incident Response
Q: How do I report a security issue?
A: Email security@integratewise.com. We respond within 24 hours.
Q: Will I be notified of a breach?
A: Yes. Within 24 hours if your data is potentially affected.
Vendor Management
Q: Who are your sub-processors?
A: Cloudflare, Supabase (AWS), OpenAI, Anthropic, n8n Cloud. Full list in Section 8.
Q: Are vendors SOC 2 certified?
A: Yes. All primary vendors have SOC 2 Type II or equivalent.
Appendix A: Security Contacts
| Purpose | Contact |
|---|---|
| Security questions | security@integratewise.com |
| Vulnerability reports | security@integratewise.com |
| DPA requests | legal@integratewise.com |
| Compliance inquiries | compliance@integratewise.com |
| General support | support@integratewise.com |
Appendix B: Document History
| Version | Date | Changes |
|---|---|---|
| 1.0 | January 2026 | Initial release |
IntegrateWise Security & Compliance Pack
Version 1.0 — January 2026
For security questions: security@integratewise.com