Skip to main content

Security & Compliance

Financial services clients don't just want video. They need trusted, compliant, auditable video. Security isn't a feature — it's the foundation.

Target posture, not current state

This page describes the security and compliance posture Percus is building toward. Many of the practices below are planned or in progress rather than in place today. For the current status, see Security › Compliance; for Percus's commitments as data processor, see the Data Protection Addendum.

Current compliance focus​

ISO 27001​

Current status — in progress

Percus is actively working toward ISO/IEC 27001 certification, together with a specialist partner. This is the certification being pursued first. Other certifications, including SOC 2 Type II, will be considered afterwards; none are currently in progress and Percus holds none today.

What It Is: International standard for information security management systems (ISMS).

Why We Need It:

  • Globally recognized (especially important for LATAM)
  • Required by many enterprises
  • Shows systematic approach to security
  • Competitive advantage vs regional competitors

What It Requires:

  • Formal ISMS documentation
  • Risk assessment methodology
  • Security controls implementation (encryption, access control, etc.)
  • Regular audits and reviews
  • Management commitment

GDPR​

What It Is: The European Union's General Data Protection Regulation — the global benchmark for personal data protection law. Even though Percus operates primarily in LATAM, GDPR compliance is a de-facto requirement because many enterprise clients have European operations, and LATAM data protection laws (Chile Ley 19.628, Peru Ley 29733, Brazil LGPD) are directly modelled on it.

Why We Need It:

  • Required by enterprise clients with EU operations or EU-based data subjects
  • LATAM regulators increasingly align with GDPR standards
  • Strengthens trust across all markets
  • Demonstrates the highest international bar for data protection

What It Requires:

  • Lawful basis for processing personal data (consent, contract, legitimate interest)
  • Right to access, rectification, erasure ("right to be forgotten"), and data portability
  • Data breach notification within 72 hours
  • Data Protection Impact Assessments (DPIA) for high-risk processing
  • Data Processing Agreements (DPA) with all sub-processors
  • Privacy by design and default

Planned implementation:

  • Consent tracking embedded in customer data pipeline
  • DSAR (Data Subject Access Request) workflow with automated data deletion
  • DPA templates ready for client and sub-processor agreements
  • Privacy-by-design enforced at architecture level (client-side rendering, no PII on servers)
  • Breach response runbook with 72-hour notification capability

Regional Compliance​

Chile: Ley 19.628 (Protección de Datos Personales)​

Requirements:

  • Explicit consent for personal data processing
  • Right to access, modify, and delete data
  • Data minimization (only collect what's needed)
  • Secure storage and transmission

Planned implementation:

  • Consent tracking in customer database
  • Data retention policies (auto-delete after campaign)
  • Encryption at rest and in transit
  • Data subject access request (DSAR) workflow

Peru: Ley 29733 (Protección de Datos Personales)​

Similar to Chile, with additions:

  • Data breach notification (5 business days)
  • Cross-border data transfer restrictions
  • Registration with national authority (required for data controllers)

Planned implementation:

  • LATAM data residency options to be evaluated (production currently runs in AWS us-east-1)
  • Breach response plan with notification templates
  • Legal counsel for cross-border compliance

General LATAM Considerations​

Banking Secrecy Laws: Most LATAM countries have strict banking secrecy regulations (e.g., Chile's Ley General de Bancos). Financial data must be protected with bank-grade security.

Our Approach:

  • Treat all financial data as highly sensitive
  • Encrypt everything (data at rest, in transit, in use when possible)
  • Access controls with need-to-know principle
  • Full audit trails for regulatory investigations

Considered for the future​

Neither of the following is in progress today, and Percus holds neither. They are certifications Percus may elect to pursue, and will be evaluated once ISO/IEC 27001 is in place. Regulatory obligations — including GDPR — are assessed separately and continuously, above.

SOC 2 Type II​

What It Is: Industry-standard audit for service organizations handling customer data. Focuses on Security, Availability, Processing Integrity, Confidentiality, and Privacy (Trust Service Criteria).

Why We Need It:

  • Required by most banks, AFPs, and insurance companies
  • Demonstrates operational maturity
  • Enables enterprise deals
  • Shows commitment to data protection

What It Requires:

  • Security policies and procedures
  • Access controls and monitoring
  • Incident response plan
  • Vendor management
  • Regular security training
  • Continuous monitoring and logging

PCI DSS (If Handling Payment Data)​

What It Is: Payment Card Industry Data Security Standard for handling credit card information.

Do We Need It?

  • Not immediately (we're not processing payments directly)
  • Potentially later if we handle payment confirmation videos with card data
  • Can be avoided by never touching card numbers (use tokenized references)

Decision: Design systems to avoid PCI scope (use bank-provided tokens, not raw card data).

Security Implementation Principles​

These aren't just checklist items. They're always-on requirements in every line of code we write.

1. Encryption Everywhere​

At Rest:

  • AWS S3 with server-side encryption (SSE-KMS)
  • RDS encrypted databases
  • Encrypted EBS volumes
  • Secrets Manager for API keys, credentials

In Transit:

  • TLS 1.3 for all external connections
  • mTLS for internal microservice communication
  • VPC isolation for sensitive services
  • No public endpoints for data processing

In Use (Where Possible):

  • Client-side encryption for highly sensitive data
  • AWS Nitro Enclaves for processing PII when needed

2. Zero Trust Architecture​

Principle: Never trust, always verify. Every request is authenticated and authorized.

Implementation:

  • No implicit trust between services
  • Service-to-service authentication via IAM roles or JWT tokens
  • Network segmentation (public/private/data subnets)
  • Principle of least privilege (minimum necessary permissions)

Example: The video rendering service can't access customer database directly. It requests data via authenticated API, which validates request, checks permissions, logs access, then returns minimal data needed.

3. Comprehensive Audit Logging​

What We Log:

  • Every data access (who, what, when, why)
  • Every API call (source, payload hash, response status)
  • Every video generated (template, data sources, recipient)
  • Every authentication attempt (success and failure)
  • Every configuration change (who modified what)

Where:

  • AWS CloudTrail (API audit logs)
  • Application logs → CloudWatch Logs
  • Security events → AWS Security Hub
  • Long-term archive → S3 Glacier (7-year retention for financial services)

Why:

  • Regulatory audits require proof of data handling
  • Incident response needs detailed logs
  • Clients need evidence for their auditors

4. Access Control & Authentication​

For Percus Staff:

  • SSO with MFA (mandatory, no exceptions)
  • Time-limited access tokens (1-hour expiry)
  • Role-based access control (RBAC)
  • Just-in-time access for production (approval required)
  • Quarterly access reviews

For Clients:

  • API authentication via OAuth 2.0 or API keys
  • Per-client encryption keys (client data isolated)
  • IP allowlisting for sensitive operations
  • Webhook signatures for callbacks

For Data Processing:

  • Service accounts with IAM roles (no long-lived credentials)
  • Secrets rotation (90-day max)
  • Encrypted environment variables

5. Data Minimization & Retention​

Collect Only What's Needed:

  • Don't request full customer profiles if only name + balance needed
  • Hash or tokenize identifiers when possible
  • Aggregate data for analytics (no raw PII)

Delete When Done:

  • Raw customer data deleted after video generation (30-day max retention)
  • Generated videos stored per client retention policy (typically 1-2 years)
  • Audit logs kept longer (7 years for financial services compliance)

Right to Be Forgotten:

  • API endpoint for data deletion requests
  • Automated workflow to purge data across all systems
  • Confirmation report for client compliance teams

6. Incident Response Plan​

Detection:

  • Automated alerts for anomalous access patterns
  • AWS GuardDuty for threat detection
  • Security Information and Event Management (SIEM) integration
  • Regular vulnerability scans

Response:

  • Incident response runbooks (pre-defined steps)
  • On-call rotation (24/7 coverage)
  • Communication templates (client notification, regulator notification)
  • Post-incident review (blameless, focus on improvements)

Timeline:

  • Detection → Response: <15 minutes for critical incidents
  • Client notification: <2 hours for data breaches
  • Regulator notification: Per local law (typically 72 hours)

7. Secure Development Lifecycle (SDL)​

Code Security:

  • Static analysis (SonarQube, CodeQL)
  • Dependency scanning (Snyk, Dependabot)
  • Secret scanning (GitGuardian, TruffleHog)
  • Pre-commit hooks (prevent secrets in git)

Review Process:

  • Mandatory code review for all changes
  • Security review for high-risk changes (data handling, auth, encryption)
  • Penetration testing before major releases

Deployment:

  • Immutable infrastructure (no manual changes)
  • Infrastructure as code (Terraform, reviewed in git)
  • Automated rollback on security alerts

Compliance Monitoring & Continuous Improvement​

Quarterly:

  • Internal security audit
  • Access review (remove unused accounts)
  • Vendor security assessment
  • Security training for all staff

Annually:

  • External penetration test
  • SOC 2 re-audit (after first certification)
  • Compliance gap analysis
  • Disaster recovery drill

Continuous:

  • Automated security monitoring
  • Vulnerability patching (<7 days for critical)
  • Security metrics dashboard (for management)

Client-Facing Security Features​

Security Reports:

  • Monthly security posture report (for enterprise clients)
  • Audit log export (for client compliance teams)
  • Penetration test results (sanitized, shared on request)

Data Residency Options:

  • Production currently runs in AWS us-east-1 (United States)
  • Multi-region backup for disaster recovery
  • Client-specific region requests (where feasible)

Compliance Documentation:

  • ISO 27001 certificate, once obtained (in progress)
  • Security questionnaire responses (standardized)
  • Data Protection Addendum

Why This Matters​

For Clients:

  • Trust that their customer data is safe
  • Evidence for their auditors
  • Reduced risk in vendor relationships

For Percus:

  • Competitive advantage (many LATAM video platforms lack certifications)
  • Higher contract values (enterprises pay for security)
  • Faster sales cycles (security checklist pre-answered)

For Engineering:

  • Clear guidelines for building features
  • No surprises during audits
  • Pride in building trustworthy systems

Key Takeaway​

Security isn't a checkbox. It's a culture.

Every engineer, designer, and PM needs to think about data protection. Every feature needs security review. Every deployment needs audit logging.

We're handling people's financial futures. Pension statements. Insurance claims. Credit reports. That's sacred trust.

We don't cut corners. We don't ship fast and fix later. We do it right the first time.

That's the Percus standard.