Security and Compliance

1. Personal data

Plumma® Connect forwards each request to the mobile network sources that can answer it and returns their answer. To bill the service, support customers and handle disputes, it keeps a limited record of each call. The table below lists what is kept and for how long.

To answer a request, the queried phone number, and for kyc_match the identity data you send, is passed to the mobile operator or authorized aggregator that serves the number. That source may be located outside the European Union, depending on the number's country.

The data Plumma keeps is processed and stored in an Amazon Web Services region inside the European Union. For the personal data of the people whose numbers you check, Plumma acts as a data processor on your behalf, under the principles of the GDPR: data minimization, purpose limitation, storage limitation and security of processing.

2. Reference standards

Plumma® Connect does not hold a formal security certification today. Its controls are designed with reference to:

• ISO/IEC 27001, for the organization of information security;
• SOC 2, for the security, availability, processing integrity, confidentiality and privacy of a service that handles data on behalf of its customers;
• OWASP guidance, for the protection of web applications and APIs.

3. API access control

• Client certificates. Every API call carries a client certificate issued by Plumma for the customer's organization (RSA 2048, valid for one year) and the identifier of the application the call belongs to. A certificate works only for the applications Plumma has enabled it for, and enablement can be withdrawn at any time.
• Separation of demo and live use. Demo numbers return synthetic data and never reach a real subscriber. Real numbers can be queried only by an approved organization, with a key enabled for the application.
• Key lifecycle. A key is shown once, can be regenerated by the customer at any time, and expires after one year.
• Validation before processing. A malformed request is rejected before any source is contacted.
• Traceability. Every response carries a correlation id that identifies the call in our records.

4. Console access control

• Passwords are stored only as BCrypt hashes. An account must verify its email address before it can sign in.
• Sign-in with Google and Microsoft accounts is supported.
• Sessions use short-lived signed tokens, valid for one hour.
• Repeated failed sign-ins are throttled, both in the application and at the firewall.
• Access is role-based: each user sees only the organizations, applications and functions their role allows.
• The console sends strict browser security headers, including HSTS, a Content Security Policy and protection against framing.

5. Encryption

• In transit. Public endpoints accept HTTPS only, with TLS 1.2 or higher (TLS 1.3 supported). Traffic between the content delivery network and the load balancers is also TLS 1.2 or higher. Calls to mobile network sources use HTTPS. Internal messaging between Plumma components uses mutually authenticated TLS.
• At rest. Databases, caches, object storage and server disks are encrypted with AES-256.

6. Protection at the edge

• Content delivery network. Public traffic reaches the service through Amazon CloudFront, which terminates TLS and absorbs network-level attacks with AWS Shield Standard.
• Web Application Firewall. AWS WAF protects every service with AWS managed rule sets for common web attacks and known malicious inputs, including the OWASP Top 10 categories. The API firewall also allows only the methods and paths the API exposes, and rejects private endpoints called without an API key.
• Rate limiting. Requests are limited per API key and per source address, and sign-in attempts are limited per address. Requests over the limit are refused with HTTP 429.
• Firewall logging. Firewall decisions are logged with credentials redacted.

7. Infrastructure

• Cloud provider. The platform runs on Amazon Web Services, in a region in the European Union, and inherits the physical and environmental security of AWS data centers.
• Network isolation. Databases, caches and the internal message broker are not reachable from the Internet: only the Plumma application servers can connect to them, and the message broker accepts connections only from within the Plumma network.
• Fixed egress addresses. Calls to mobile network sources leave from a fixed set of addresses that the sources can allowlist.
• No long-lived deployment credentials. Deployments authenticate to AWS with short-lived credentials issued per run. Each server runs with an identity limited to the resources it needs.
• Audit trail. Every administrative action on the cloud account is recorded, with log integrity validation.

8. Vulnerability management

• Patching. Operating system and runtime patches are applied automatically every week. Database minor versions are upgraded automatically.
• Dependencies. A software bill of materials (CycloneDX) is produced for every release. Third-party components are scanned for known vulnerabilities every week and on every change to the main branch, and dependency updates are proposed automatically.
• Controlled delivery. Every change is tracked in version control and deployed through an automated pipeline.

9. Availability and recovery

• The API runs on at least two servers spread across separate Availability Zones, behind a load balancer, with automatic scaling and automatic replacement of failed servers.
• Releases are deployed in rolling batches, so the service stays available during updates.
• The database is backed up automatically every day, with point-in-time recovery over the last 7 days, and is protected against accidental deletion.