Yirla Security Review - Frequently Asked Questions
“Yirla is architected as a read-only, PII-free, tenant-isolated analytics system, with encryption everywhere, no standing super-admin access, and auditability built into every layer.”
A. DATA — What we ingest, touch, and don’t touch
1. What customer data does Yirla collect?
We ingest advertising performance metadata only: impressions, clicks, spend, creatives, timestamps, targeting attributes at an aggregate level. We do not collect PII, user-level identifiers, emails, IPs, or LinkedIn member data.
2. Do you store raw data or transformed data?
Both. Raw data is stored immutably for audit/debug purposes. Transformed/aggregated datasets are used for analytics and surfaced to users. Raw and derived datasets are logically separated.
3. Is any PII stored or processed?
No. Our data model is explicitly designed to be PII-free. If a source unexpectedly includes PII, it is rejected at ingestion.
4. Is customer data ever mixed across tenants?
No. Data is logically isolated by tenant ID at every layer: ingestion, storage, query, and application logic. There is no shared query context across tenants.
5. Do you train models on customer data?
No customer data is used for training foundation models. Any analytics or heuristics are rule-based or operate only on that customer’s isolated data.
B. STORAGE — Where data lives and how it’s locked down
6. Where is data stored geographically?
Primary storage is in AWS (US regions). We can support region pinning if required by contract.
7. How is data encrypted at rest?
All data at rest is encrypted using AES-256 via AWS-managed KMS keys. No plaintext storage, no exceptions.
8. Who controls the encryption keys?
Keys are managed by AWS KMS with restricted IAM policies. We can support customer-managed keys (CMK) for enterprise contracts.
9. How long do you retain data?
Default retention is 3 months, configurable per customer. Customers can request deletion at any time, and deletes propagate across raw, derived, and backup layers.
10. Are backups encrypted and isolated?
Yes. Encrypted backups are stored in separate accounts, access-restricted, and tested quarterly for restore integrity.
C. SECURITY — Our policies
11. How is data encrypted in transit?
All data in transit uses TLS 1.2+. Internal service-to-service traffic is also encrypted—no flat internal network trust.
12. Do you have a “God mode” or super-admin access?
There is no standing God mode. Privileged access is time-bound, audited, and requires MFA. Emergency access uses break-glass procedures with post-incident review.
13. Who internally can access customer data?
Only a small, role-restricted subset of engineers for support/debugging, and only with explicit approval. All access is logged.
14. How do you handle secrets (API keys, tokens)?
Secrets are stored in AWS Secrets Manager, rotated regularly, and never hard-coded or logged.
15. How do you protect against data exfiltration?
Network egress is restricted, IAM policies are least-privilege, and anomalous access patterns trigger alerts.
16. Have you done penetration testing or audits?
We perform regular internal security reviews and are on a roadmap for third-party penetration testing (Cobalt) and SOC-2 as we scale enterprise usage.
D. USAGE & OPERATIONAL RISK — “What happens if…”
17. Can Yirla write back to ad platforms or mutate data?
No. Yirla is read-only. We do not modify campaigns, bids, or creatives unless explicitly authorized in future enterprise workflows.
18. What happens if our credentials are compromised?
Credentials are scoped read-only, can be revoked instantly, and compromise does not expose PII or cross-tenant data.
19. How do you log and monitor security events?
We maintain centralized logging with immutable audit logs (AWS S3 + Object Lock - WORM), (DataDog) real-time alerts, and incident response playbooks. Infrastructure and Cloud activity logs are on AWS Cloudtrail. Our security monitoring and alerting are on AWS GuardDuty. AWS IAM + MFA for Access control.
20. What’s your incident response posture?
Defined escalation paths, customer notification SLAs, root-cause analysis, and remediation timelines aligned with enterprise expectations.