Enhance Your Jira Security with AI
Security Statement
At KDDLC AI Solutions (trading as EmbankAI), security and data protection are fundamental to our operations. This Security Statement describes the measures we implement to protect Embank Clarity and your data.
Why Security Matters
In today’s digital landscape, safeguarding your Jira instance and AI provider accounts is crucial. EmbankAI is dedicated to providing top-notch security solutions that protect your data and enhance your workflow efficiency. Our mission is to empower teams by ensuring their tools are as secure as they are innovative.
Understanding Shared Responsibility
At EmbankAI, we believe in a collaborative approach to security. Our shared responsibility model ensures that while we manage app security, encryption, and compliance, you focus on user access management and data classification. Together, we create a secure environment that fosters innovation and trust.
User Access Management
Effectively managing user access in Jira is crucial for maintaining security and operational efficiency. Start by defining clear roles and permissions to ensure users have access only to the resources they need. Regularly review and update these permissions to adapt to changes in team structure or project requirements.
Implementing multi-factor authentication (MFA) adds an additional layer of security, protecting your Jira instance from unauthorized access. Encourage users to use strong, unique passwords and provide training on recognizing phishing attempts. By prioritizing these practices, you can safeguard your Jira environment and enhance productivity.
Data Classification
Our Commitment
– Industry-standard security practices
– Encryption at rest and in transit
– Regular security assessments
– Transparent incident reporting
– Compliance with data protection regulations
Compliance Assurance
Security Statement
**Last Updated:** January 22, 2026
**Version:** 1.0
## Overview
At KDDLC AI Solutions (trading as EmbankAI), security and data protection are fundamental to our operations. This Security Statement describes the measures we implement to protect Embank Clarity and your data.
**Our Commitment:**
– Industry-standard security practices
– Encryption at rest and in transit
– Regular security assessments
– Transparent incident reporting
– Compliance with data protection regulations
—
## 1. Architecture & Data Flow
### 1.1 Infrastructure
**Hosting Environment:**
– **Forge App:** Hosted on Atlassian’s Forge platform (SOC 2 Type II compliant)
– **Licensing API:** AWS Lambda in EU-Ireland region (`eu-west-1`)
– **Database:** AWS DynamoDB with encryption at rest
– **File Storage:** Atlassian Forge Storage (managed by Atlassian)
**Technology Stack:**
– **Runtime:** Node.js 20.x
– **Framework:** Atlassian Forge SDK
– **Backend:** AWS Lambda (serverless)
– **Database:** AWS DynamoDB (NoSQL)
– **Payments:** Stripe (PCI DSS Level 1 compliant)
### 1.2 Data Flow Architecture
“`
┌─────────────────┐
│ Jira Cloud │ (Your Environment)
│ (Atlassian) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Embank Clarity │ (Forge App)
│ – Reviews │
│ – Config │
│ – Encryption │
└────┬───────┬────┘
│ │
│ └──────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌──────────────────┐
│ Your AI Provider│
│ – OpenAI │
│ – Anthropic │ │
│ – AWS Bedrock │
└─────────────────┘ └──────────────────┘
│ │
│ ▼
│ ┌──────────────────┐
│ │ – Usage metadata │
│ └──────────────────┘
│
▼
┌─────────────────┐
│ Atlassian │ (Payment Processing)
└─────────────────┘
“`
**Key Points:**
– ✅ Ticket content flows **directly** from Jira → Your AI Provider → Jira
– ✅ We **never** store or process your ticket content
– ✅ Our API only validates licenses and enforces usage limits
– ✅ All communications use HTTPS/TLS 1.2+
—
## 2. Data Protection
### 2.1 Data Classification
**Critical Data (Highest Protection):**
– Customer AI Provider API keys
– **Encryption:** AES-256-GCM
– **Storage:** Atlassian Forge Storage (encrypted at rest)
– **Access:** Encrypted by installation, only decryptable by your Forge app instance
– **Retention:** Deleted within 30 days of subscription cancellation
**Sensitive Data (High Protection):**
– Subscription information (tenant ID, billing status)
– Configuration data (project settings, review rules)
– Usage metrics (review counts, timestamps)
– **Encryption:** TLS in transit, encrypted at rest (AWS DynamoDB)
– **Access:** Role-based access control (RBAC)
– **Retention:** See Privacy Policy Section 5
**Public Data (Standard Protection):**
– Product documentation
– Marketing content
– Public changelog
**Data We Do NOT Collect or Store:**
– ❌ Jira ticket content (descriptions, comments)
– ❌ User personal information beyond Atlassian account IDs
– ❌ AI-generated review feedback (stored only in Jira comments)
– ❌ Attachments or files
– ❌ Authentication credentials (we use Atlassian’s OAuth)
### 2.2 Encryption
**Encryption at Rest:**
**API Keys (AES-256-GCM):**
– **Algorithm:** AES-256-GCM (Galois/Counter Mode)
– **Key Length:** 256 bits
– **Authentication:** 16-byte authentication tag
– **IV:** 12-byte random initialization vector per encryption
– **Key Management:** Stored in Forge environment variables (separate from data)
– **Implementation:**
“`typescript
// Simplified example
encrypt(plaintext: string): string {
const key = Buffer.from(ENCRYPTION_KEY, ‘base64’); // 256-bit key
const iv = crypto.randomBytes(12); // Random IV
const cipher = crypto.createCipheriv(‘aes-256-gcm’, key, iv);
const ciphertext = cipher.update(plaintext, ‘utf8’, ‘base64’) + cipher.final(‘base64’);
const authTag = cipher.getAuthTag(); // Authentication tag
return base64(iv + ciphertext + authTag);
}
“`
**Database (AWS DynamoDB):**
– **Method:** AWS-managed encryption at rest
– **Standard:** AES-256
– **Key Management:** AWS Key Management Service (KMS)
**Encryption in Transit:**
– **Protocol:** TLS 1.2+ (Transport Layer Security)
– **Cipher Suites:** Strong ciphers only (no weak or deprecated ciphers)
– **Certificate Authority:** AWS Certificate Manager (ACM)
– **HSTS:** Strict-Transport-Security header enabled
– **All API endpoints:** HTTPS only (HTTP redirects to HTTPS)
**No Unencrypted Data:**
– ✅ All data encrypted in transit (TLS)
– ✅ All sensitive data encrypted at rest
– ✅ No plaintext storage of API keys
– ✅ Secure key derivation and storage
### 2.3 Data Isolation
**Multi-Tenancy:**
– Each Jira instance (tenant) has isolated data
– Tenant ID used to partition all data access
– No cross-tenant data access possible
**Access Control:**
– Forge app can only access its installation’s data
– DynamoDB queries filtered by tenant ID
– AWS IAM policies enforce least privilege
—
## 3. Access Control
### 3.1 Authentication
**Forge App Authentication:**
– **Method:** Atlassian’s Forge platform handles all authentication
– **OAuth 2.0:** Used for Jira API access
– **No Password Storage:** We never store user passwords
– **Session Management:** Managed by Atlassian
**Licensing API Authentication:**
– **Method:** Bearer token (HMAC-based shared secret)
– **Token Storage:** AWS environment variables (encrypted by AWS)
– **Validation:** Every request validated before processing
– **No Public Endpoints:** Except Stripe webhook (signature-verified)
**Stripe Webhook Verification:**
– **Method:** HMAC-SHA256 signature verification
– **Secret:** Stored securely in AWS environment
– **Validation:** Every webhook event verified before processing
– **Replay Protection:** Timestamp validation
**Admin Access (Internal):**
– **MFA Required:** Multi-factor authentication mandatory for all admin accounts
– **SSH Keys:** Required for AWS access (no password auth)
– **IAM Roles:** Least privilege principle
– **Audit Logs:** All admin actions logged
### 3.2 Authorization
**Role-Based Access Control (RBAC):**
**Jira Users:**
– Must have appropriate Jira permissions to use the App
– Read access: View review comments
– Write access: Trigger manual reviews (via `/clarity review` command)
– Admin access: Configure App settings (Jira admins only)
**Internal (Embank Staff):**
– **Developers:** Access to development/staging environments only
– **Support:** Read-only access to logs (no access to encrypted API keys)
– **Admins:** Limited access to production (MFA required, logged)
– **Finance:** Read-only access to Stripe dashboard
**Principle of Least Privilege:**
– Users granted minimum necessary permissions
– Permissions reviewed quarterly
– Temporary elevated access expires after 24 hours
### 3.3 Network Security
**Firewall & Network Segmentation:**
– **AWS Security Groups:** Restrict inbound/outbound traffic
– **API Gateway:** Rate limiting, DDoS protection
– **AWS Shield Standard:** DDoS protection (automatic)
– **No Direct Database Access:** Only via Lambda functions
**API Rate Limiting:**
– **Per-tenant limits:** Prevent abuse and ensure fair use
– **Cloudflare (Future):** Additional DDoS protection and WAF
**IP Allowlisting (Enterprise – Optional):**
– Available upon request for Enterprise customers
– Restrict API access to specific IP ranges
—
## 4. Application Security
### 4.1 Secure Development Lifecycle (SDLC)
**Development Practices:**
– **Code Reviews:** All code reviewed before merge
– **Branch Protection:** No direct commits to main/production branches
– **Automated Testing:** Unit tests, integration tests
– **Static Analysis:** TypeScript strict mode, ESLint
– **Dependency Scanning:** Automated vulnerability scanning (npm audit)
**Security Testing:**
– **SAST (Static Analysis):** Automated code scanning
– **Dependency Audits:** Weekly npm audit and Dependabot alerts
– **Manual Reviews:** Security review for major releases
– **Penetration Testing:** Annual third-party penetration tests (planned)
**Secrets Management:**
– **No Hardcoded Secrets:** All secrets in environment variables
– **Environment Isolation:** Separate dev/staging/production secrets
– **Secret Rotation:** Quarterly rotation for production secrets
– **Vault (Future):** Migrate to HashiCorp Vault or AWS Secrets Manager
### 4.2 Vulnerability Management
**Dependency Updates:**
– **Automated Alerts:** Dependabot monitors dependencies
– **Response Time:**
– Critical vulnerabilities: Patched within 24 hours
– High vulnerabilities: Patched within 7 days
– Medium/Low vulnerabilities: Next release cycle
– **Testing:** All updates tested before production deployment
**Vulnerability Disclosure:**
– **Responsible Disclosure:** Coordinated disclosure process
– **Communication:** Affected customers notified within 72 hours
– **Transparency:** Public security advisories for confirmed vulnerabilities
**Bug Bounty Program (Planned):**
– Private bug bounty program for security researchers
– Responsible disclosure rewards
### 4.3 Input Validation & Output Encoding
**Input Validation:**
– All user inputs validated and sanitized
– Type checking with TypeScript
– Schema validation for API requests
– Protection against:
– SQL injection (N/A – NoSQL database)
– XSS (Cross-Site Scripting)
– CSRF (Cross-Site Request Forgery)
– Command injection
– Path traversal
**Output Encoding:**
– All outputs properly encoded
– Jira API calls use Atlassian’s SDKs (built-in protection)
– No direct HTML rendering of user content
### 4.4 Secure API Design
**API Security:**
– **Authentication Required:** All endpoints (except webhooks) require auth
– **Rate Limiting:** Per-tenant and global rate limits
– **Input Validation:** Strict schema validation (JSON Schema)
– **Error Handling:** Generic error messages (no sensitive info leaked)
– **CORS:** Restrictive CORS policy
– **Content Security Policy (CSP):** Enforced in frontend
—
## 5. Infrastructure Security
### 5.1 Cloud Security (AWS)
**AWS Best Practices:**
– **IAM:** Least privilege policies for all services
– **VPC:** (Future) Dedicated VPC for production
– **CloudWatch:** Monitoring and alerting
– **CloudTrail:** Audit logs for all AWS API calls
– **Config:** Track configuration changes
– **GuardDuty:** Threat detection (planned)
**Lambda Security:**
– **Isolated Execution:** Each function execution is isolated
– **Environment Variables:** Encrypted at rest (AWS KMS)
– **No Public Internet (Future):** Lambda in VPC with NAT gateway
– **Security Updates:** Automatic runtime patching by AWS
**DynamoDB Security:**
– **Encryption:** AES-256 at rest (AWS-managed keys)
– **Backups:** Automatic point-in-time recovery enabled
– **Access Control:** IAM policies restrict access to Lambda only
– **Audit Logs:** All access logged in CloudTrail
### 5.2 Monitoring & Logging
**Application Logging:**
– **Forge Logs:** All app events logged (via Forge CLI)
– **AWS CloudWatch:** Lambda function logs and metrics
– **Retention:**
– Development: 7 days
– Production: 30 days
– **Log Redaction:** Sensitive data (API keys, tokens) redacted
**Security Monitoring:**
– **Failed Auth Attempts:** Monitored and alerted
– **Anomalous Activity:** Unusual usage patterns flagged
– **Error Rates:** High error rates trigger alerts
– **Latency Monitoring:** Performance degradation alerts
**Audit Logs:**
– **Admin Actions:** All configuration changes logged
– **Billing Events:** Subscription changes logged
– **License Validations:** All license checks logged (tenant ID only)
– **Retention:** 1 year for compliance
**Alerting:**
– **Slack Alerts:** Critical errors and security events
– **Email Alerts:** Security incidents escalated to on-call engineer
– **PagerDuty (Future):** 24/7 incident response
### 5.3 Backup & Disaster Recovery
**Data Backups:**
– **DynamoDB:** Point-in-time recovery enabled (35-day retention)
– **Forge Storage:** Managed by Atlassian (no direct access)
– **Configuration:** Infrastructure as code (Terraform/Serverless framework)
**Disaster Recovery Plan:**
– **RTO (Recovery Time Objective):** 4 hours
– **RPO (Recovery Point Objective):** 1 hour
– **Backup Testing:** Quarterly restore tests
– **Runbook:** Documented recovery procedures
**Business Continuity:**
– **Multi-AZ Deployment:** DynamoDB and Lambda span multiple availability zones
– **Automatic Failover:** AWS handles infrastructure failover
– **Data Replication:** DynamoDB global tables (future, for multi-region)
—
## 6. Compliance & Certifications
### 6.1 Current Compliance
**GDPR (General Data Protection Regulation):**
– ✅ Data processing agreements available
– ✅ User rights supported (access, deletion, portability)
– ✅ Privacy by design principles
– ✅ Data retention policies documented
– ✅ Cross-border transfer safeguards (SCCs)
**Atlassian Forge Security Requirements:**
– ✅ Secure authentication (no Basic Auth in production)
– ✅ Published security statement (this document)
– ✅ No sensitive data in logs
– ✅ Encrypted credential storage
**PCI DSS (Payment Card Industry):**
– ✅ We do NOT store payment card data
– ✅ All payments processed by Stripe (PCI DSS Level 1 certified)
– ✅ No card data touches our infrastructure
### 6.2 Third-Party Security
**Sub-Processors & Their Certifications:**
**Atlassian (Forge Platform):**
– SOC 2 Type II
– ISO 27001
– ISO 27018
– Privacy Shield (EU-US)
– See: [Atlassian Trust Center](https://www.atlassian.com/trust)
**AWS (Hosting):**
– SOC 1, 2, 3
– ISO 27001, 27017, 27018
– PCI DSS Level 1
– GDPR compliant
– See: [AWS Compliance](https://aws.amazon.com/compliance/)
**Stripe (Payments):**
– PCI DSS Level 1 (highest)
– SOC 1 Type II, SOC 2 Type II
– ISO 27001
– See: [Stripe Security](https://stripe.com/docs/security/stripe)
—
## 7. Incident Response
### 7.1 Security Incident Management
**Incident Response Team:**
– **On-call rotation:** 24/7 coverage
– **Response time:** Critical incidents within 1 hour
– **Escalation:** Defined escalation procedures
**Incident Response Process:**
**Phase 1: Detection & Analysis (0-1 hour)**
– Automated monitoring detects anomaly
– On-call engineer alerted (PagerDuty/Slack)
– Initial assessment and severity classification
**Phase 2: Containment (1-4 hours)**
– Isolate affected systems
– Prevent further damage
– Preserve evidence for forensics
**Phase 3: Eradication (4-24 hours)**
– Identify and remove root cause
– Apply patches or configuration changes
– Verify threat is eliminated
**Phase 4: Recovery (24-48 hours)**
– Restore services to normal operation
– Monitor for recurrence
– Validate system integrity
**Phase 5: Post-Incident (48-72 hours)**
– Root cause analysis (RCA)
– Document lessons learned
– Implement preventive measures
– Customer communication (if affected)
### 7.2 Data Breach Response
**Notification Timeline:**
**Within 24 hours:**
– Internal incident response team activated
– Preliminary assessment completed
– Affected systems identified
**Within 72 hours:**
– Affected customers notified (email)
– Data protection authorities notified (if GDPR applies)
– Remediation in progress
**Within 7 days:**
– Detailed incident report provided to affected customers
– Root cause analysis completed
– Preventive measures implemented
**Customer Notification Includes:**
– Nature of the breach
– Data affected
– Potential impact
– Remediation steps taken
– Recommended customer actions
### 7.3 Vulnerability Disclosure
**Responsible Disclosure Process:**
**For Security Researchers:**
1. **Report:** Email security@embank.ai with details
2. **Acknowledgment:** We respond within 24 hours
3. **Investigation:** We investigate and validate (1-7 days)
4. **Fix:** We develop and deploy a fix (1-30 days depending on severity)
5. **Disclosure:** Coordinated public disclosure (after fix is deployed)
**Disclosure Policy:**
– **90-day window:** We aim to fix and disclose within 90 days
– **Critical vulnerabilities:** Expedited fix (24-72 hours)
– **Recognition:** Security researchers credited (with permission)
– **Rewards:** Bug bounty program (planned)
**Out of Scope:**
– Social engineering attacks
– Physical attacks
– Denial of service (DoS) attacks
– Spam or abuse of contact forms
—
## 8. Privacy & Data Handling
### 8.1 Data Minimization
**We collect only what’s necessary:**
– Subscription metadata (for billing)
– Usage metrics (for rate limiting)
– Configuration data (for App operation)
**We do NOT collect:**
– Jira ticket content
– User personal information (beyond Atlassian account IDs)
– Browsing history or analytics cookies
### 8.2 Data Sovereignty
**Data Storage Locations:**
– **Forge App Data:** Stored by Atlassian (varies by your Jira region)
– **Licensing API:** AWS EU-Ireland (`eu-west-1`)
– **Payment Data:** Stripe (US and EU regions)
**Cross-Border Transfers:**
– EU to US transfers protected by Standard Contractual Clauses (SCCs)
– Stripe is Privacy Shield certified (for EU-US transfers)
– AWS operates EU data centers (data residency)
### 8.3 Data Retention & Deletion
**Retention Periods:**
– **Encrypted API Keys:** 30 days post-cancellation, then deleted
– **Configuration Data:** 90 days post-cancellation, then deleted
– **Subscription Metadata:** 7 years (legal/accounting requirement), then anonymized
– **Usage Logs:** 30 days, then deleted
**Data Deletion Process:**
1. Customer cancels subscription or requests deletion
2. Automated deletion job scheduled
3. Data marked for deletion
4. After retention period: Data permanently deleted (overwritten)
5. Deletion confirmed in audit logs
**User Rights:**
– **Access:** Request a copy of your data (email privacy@embank.ai)
– **Deletion:** Request immediate deletion (after subscription ends)
– **Portability:** Export your configuration data
—
## 9. Third-Party Security
### 9.1 AI Provider Security
**Important:** When you use the App, your Jira ticket content is sent to your chosen AI Provider. **You** control this relationship:
**Your Responsibilities:**
– Choose a trustworthy AI Provider
– Review their security and privacy policies
– Manage your API key securely
– Comply with their terms of service
**EmbankAI’s Role:**
– We encrypt your API key (AES-256-GCM)
– We facilitate the data transfer (Jira → AI Provider)
– We do NOT store or process your ticket content
**AI Provider Security Reviews:**
– **OpenAI:** SOC 2 Type II, encryption in transit and at rest
– [OpenAI Security](https://openai.com/security/)
– **Anthropic:** Enterprise-grade security, SOC 2 Type II
– [Anthropic Security](https://www.anthropic.com/security)
– **AWS Bedrock:** AWS security standards (see above)
– [AWS Bedrock Security](https://aws.amazon.com/bedrock/security/)
### 9.2 Vendor Risk Management
**Vendor Selection Criteria:**
– Security certifications (SOC 2, ISO 27001)
– Data protection compliance (GDPR)
– Incident response capabilities
– Financial stability
– Reputation and track record
**Ongoing Monitoring:**
– Quarterly vendor security reviews
– Monitor for security incidents or breaches
– Annual contract reviews
– Vendor risk assessments
—
## 10. Employee Security
### 10.1 Access Management
**Employee Access Principles:**
– **Least Privilege:** Minimum necessary access
– **Need-to-Know:** Access granted based on job role
– **Time-Limited:** Elevated access expires automatically
– **Audited:** All access logged and reviewed
**Access Reviews:**
– Quarterly reviews of all employee access
– Immediate revocation upon role change or departure
– Temporary access expires after 24 hours
### 10.2 Security Training
**Required Training:**
– **Onboarding:** Security awareness training (first week)
– **Annual Refresher:** Mandatory security training
– **Phishing Tests:** Quarterly simulated phishing campaigns
– **Incident Response:** All engineers trained on response procedures
**Topics Covered:**
– Secure coding practices
– Social engineering awareness
– Password security (MFA)
– Data handling and classification
– Incident reporting
### 10.3 Background Checks
– **All Employees:** Background checks before hire (where legally permitted)
– **Contractors:** Same requirements as employees
– **Vendors:** Due diligence before engagement
—
## 11. Physical Security
**Office Security (if applicable):**
– Badge access control
– Visitor sign-in and escort
– Secure disposal of physical documents (shred)
– Clean desk policy
**Data Center Security:**
– We do not operate physical data centers
– Rely on AWS and Atlassian’s physical security
– AWS data centers: SOC 1, 2, 3 certified
– 24/7 surveillance, biometric access
—
## 12. Continuous Improvement
### 12.1 Security Roadmap
**Q1 2026:**
– ✅ Publish security statement (this document)
– ✅ Implement AES-256-GCM encryption
– ✅ Enable DynamoDB point-in-time recovery
**Q2 2026:**
– [ ] Launch private bug bounty program
– [ ] Implement secret rotation automation
– [ ] Add AWS GuardDuty for threat detection
**Q3 2026:**
– [ ] Annual penetration testing
– [ ] SOC 2 Type II audit preparation
**Q4 2026:**
– [ ] Achieve SOC 2 Type II certification
– [ ] Implement AWS VPC for Lambda functions
**2027:**
– [ ] ISO 27001 certification
– [ ] Multi-region deployment (disaster recovery)
### 12.2 Security Metrics
**Key Performance Indicators (KPIs):**
– **Vulnerability Response Time:** < 24 hours for critical
– **Incident Response Time:** < 1 hour for detection
– **Patch Deployment Time:** < 7 days for high severity
– **Dependency Vulnerabilities:** 0 critical, 0 high
– **Failed Auth Attempts:** Monitor and alert
– **Uptime:** > 99.5%
**Quarterly Security Reviews:**
– Review access logs
– Audit employee access
– Review vendor risk assessments
– Update threat models
– Test disaster recovery procedures
—
## 13. Transparency & Communication
### 13.1 Security Updates
**How We Communicate:**
– **Email:** Critical security updates sent to all customers
– **Status Page:** (Planned) Real-time system status
– **Changelog:** Security-related changes documented
– **Blog:** Security best practices and tips
**What We Communicate:**
– Security incidents (if customers are affected)
– Significant security enhancements
– Compliance certifications achieved
– Changes to security policies
### 13.2 Customer Responsibilities
**You are responsible for:**
– **Jira Security:** Securing your Jira instance (managed by Atlassian)
– **AI Provider Security:** Securing your AI Provider account and API key
– **User Management:** Managing user access in your Jira instance
– **Data Classification:** Classifying your Jira data appropriately
– **Compliance:** Ensuring your use complies with your organization’s policies
**Shared Responsibility Model:**
“`
┌─────────────────────────────────────┐
│ Your Responsibility │
├─────────────────────────────────────┤
│ – Jira user access management │
│ – AI Provider account security │
│ – Data classification │
│ – Internal compliance │
└─────────────────────────────────────┘
↕ (Shared)
┌─────────────────────────────────────┐
│ EmbankAI’s Responsibility │
├─────────────────────────────────────┤
│ – App security (code, infrastructure)│
│ – Encryption (API keys) │
│ – License validation │
│ – Compliance certifications │
│ – Incident response │
└─────────────────────────────────────┘
“`
—
## 14. Contact & Reporting
### 14.1 Security Contact
**Report Security Vulnerabilities:**
– **Email:** security@embank.ai
– **Response Time:** Within 24 hours
– **Encryption:** PGP key available upon request
**What to Include:**
– Detailed description of the vulnerability
– Steps to reproduce
– Potential impact assessment
– Your contact information (for follow-up)
### 14.2 General Security Inquiries
**For Questions About:**
– Security practices
– Compliance certifications
– Data handling
– Privacy concerns
**Contact:**
– **Email:** security@embankai.com
– **Privacy:** privacy@embankai.com
– **Support:** support@embankai.com
### 14.3 Security Documentation
**Additional Resources:**
– **Privacy Policy:** [PRIVACY_POLICY.md]
– **Terms of Service:** [TERMS_OF_SERVICE.md]
– **Data Processing Agreement:** Available upon request (email privacy@embank.ai)
– **Sub-Processor List:** See Section 9.1
—
## 15. Acknowledgments
We are grateful to:
– **Atlassian** for providing a secure Forge platform
– **AWS** for robust cloud infrastructure
– **Security researchers** who responsibly disclose vulnerabilities
– **Our customers** for trusting us with their data
—
## Summary (TL;DR)
**🔒 Encryption:**
– API keys: AES-256-GCM encryption at rest
– All traffic: TLS 1.2+ encryption in transit
– Database: AWS-managed encryption
**🚫 Data We Don’t Collect:**
– Your Jira ticket content
– User personal information
– AI review feedback (stored only in Jira)
**✅ What We Do:**
– Encrypt your AI Provider API keys
– Validate licenses and enforce usage limits
– Process subscription payments (via Stripe)
– Monitor for security threats
**🛡️ Infrastructure:**
– JIRA / Atlassian Servers
–
**📞 Report Security Issues:**
– Email: security@embank.ai
– Response: Within 24 hours
—
**Document Version:** 1.0
**Last Updated:** January 22, 2026
**Next Review:** April 22, 2026 (quarterly)
**Questions or Concerns?**
Contact: contact@embankai.com
© 2026 KDDLC AI Solutions (trading as EmbankAI). All rights reserved.
Phone
(555) 123-4567
Address
5678 Embank Lane, Suite 200, New York, NY 10001