Security Policy

Last updated:

This Security Policy describes the information security management system (ISMS) PT UNIT GLOBAL SYSTEM operates to protect merchant data, customer data, and the integrity of our payment services. It is aligned with BSSN Regulation 1 of 2024, Bank Indonesia information-security expectations for payment service providers, UU PDP (Law 27 of 2022), the PCI DSS attestation we hold for our cardholder data environment, and the inherited compliance posture of our infrastructure provider Amazon Web Services (Asia Pacific Jakarta region).

1. Information security management system

UnitPay maintains a documented ISMS owned by the Chief Information Security Officer (CISO). The ISMS scope covers production payment processing, merchant cabinet, KYC and AML services, and supporting back-office systems. Policies and controls within scope are reviewed at least annually and after every material incident or regulatory change. Out-of-scope corporate IT (workstations not used for production access, marketing tooling, sales CRM) is governed by a separate baseline policy that nevertheless inherits the encryption, access-control, and incident-response standards described here.

Governance ownership flows from the board through a Risk Committee that meets at least quarterly to review security posture, incidents, audit findings, and the remediation pipeline. The CISO reports security metrics monthly to the executive team.

The control framework is mapped to ISO 27001 Annex A and to the BSSN-recognised SNI ISO/IEC 27001:2022 control set so that internal audits, future external assessments, and regulator examinations can use a common language. Roles and responsibilities are documented in a RACI matrix kept current with the organisational chart, and security objectives form part of the annual planning cycle that the board approves.

2. Access control

Access to production systems is role-based and granted on a least-privilege basis. Multi-factor authentication is mandatory for every account that touches production, irrespective of role. Privileged operations (deployments, database administration, secrets rotation) require named-individual approval and are logged with full command capture.

Authentication factors permitted for production access are:

  • Hardware security keys (FIDO2/WebAuthn) for engineers and administrators.
  • Time-based one-time password (TOTP) authenticators for general staff with production touchpoints.
  • Single sign-on through the corporate identity provider with conditional-access policies enforcing device posture and network context.

Shared, generic, or service-team accounts are not permitted for human use; service accounts are limited to machine workflows and have their own least-privilege permission set.

Access reviews occur quarterly: each role's membership is re-attested by the role owner, and orphaned accounts are removed within seven days of detection. Departing staff lose all production access on the same business day as their last working day; recoverable artefacts (laptops, hardware tokens) are collected and rotated.

Access to merchant or customer personal data beyond the minimum required by role is treated as a privacy incident and is investigated under the same severity framework as a security incident. Just-in-time elevation is preferred over standing privilege: where a task requires elevated rights, those rights are granted for a bounded session, scoped to the task at hand, and revoked automatically when the session ends.

3. Encryption

Data in transit between clients, our edge, and internal services uses TLS 1.2 or higher with modern cipher suites; TLS 1.0 and 1.1 are disabled at the edge. HTTP Strict Transport Security is enforced at the production edge with includeSubDomains and preload. Internal service-to-service traffic uses mutual TLS where both endpoints support it; legacy traffic that does not is restricted to private network segments and is on a documented decommission path.

Data at rest is encrypted using AWS Key Management Service with customer-managed keys (CMK) provisioned in the Asia Pacific Jakarta region (ap-southeast-3). Keys are rotated at least annually. Backups are encrypted with the same KMS keys and never written to a region outside ap-southeast-3.

Application-level field encryption is applied to high-sensitivity attributes (KYC document images, biometric template hashes, banking instrument numbers) on top of the storage-level CMK, so that database-tier compromise does not expose plaintext. Key access is logged by KMS and reviewed alongside the access-control evidence described in section 2; key destruction is a controlled, multi-party operation never performed by a single individual.

4. Vulnerability management

Dependency scanning runs on every commit through our continuous integration pipeline; high or critical vulnerabilities block release until patched. Container images are rebuilt at least weekly to absorb base-image security updates. Cloud configuration is monitored continuously through AWS Config and GuardDuty, with deviations from approved baselines alerting the security team.

Patching service-level objectives are:

  • Critical: remediated within 7 days of disclosure or 24 hours where active exploitation is observed.
  • High: remediated within 30 days.
  • Medium: remediated within 90 days.
  • Low: addressed in regular release cycles.

Documented exceptions are accepted only where a compensating control is in place and the residual risk is approved by the CISO. Exception records are reviewed at least quarterly.

Internal vulnerability assessment is performed quarterly by the security team. External penetration testing is performed annually by an independent qualified third party; findings are tracked to closure with severity-based service-level objectives.

Coordinated security research is welcomed: independent researchers acting in good faith may report findings to security@unitpay.net and will receive an acknowledgement within two working days. Threat intelligence feeds covering payment-industry and Indonesian-market threats are ingested into the security operations workflow so that emerging tactics, techniques, and procedures inform our detection rules and patching priorities.

5. Incident response

UnitPay operates a Computer Incident Response Team (CIRT) structured in line with BSSN Regulation 1 of 2024. The CIRT classifies incidents by severity (low, medium, high, critical) using documented criteria covering data exposure, service availability, regulator-reportable conditions, and customer impact.

Severity-based response targets are:

  • Critical: 15 minutes to first responder acknowledgement, 60 minutes to mitigation start, 24-hour status updates until closure.
  • High: 30 minutes to acknowledgement, 4 hours to mitigation start, daily status updates.
  • Medium: 4 working hours to acknowledgement, mitigation within the next working day, weekly status updates.
  • Low: next working day acknowledgement, mitigation tracked in the regular maintenance backlog.

The CIRT operates a 24x7 on-call rotation. Incident drills are run at least twice a year covering both technical containment and external-communication scenarios so that role responsibilities are practised before they are needed in a real event.

Personal data breaches that meet the UU PDP Article 46 threshold are notified to the Personal Data Protection Authority and to affected data subjects within 3 x 24 hours of confirmed determination. Notification content includes the categories of data affected, estimated impact, immediate mitigation taken, and contact for further information. The Data Protection Officer can be reached at dpo@unitpay.net; security incidents may be reported to security@unitpay.net.

Every confirmed incident generates a written post-incident review with timeline, root cause, contributing factors, customer impact, and corrective-action plan; reviews are tracked through completion of remediation. Where a security incident has merchant-visible operational impact, affected merchants receive direct notification with the information they need to brief their own customers and regulators.

6. Business continuity and resilience

Production workloads run multi-AZ within ap-southeast-3 to absorb single-AZ failures. Recovery point objective (RPO) for transactional data is 5 minutes; recovery time objective (RTO) for production payment processing is 60 minutes. Backup retention is 30 days for operational restore plus 7 years for archive in line with Bank Indonesia audit requirements. Backups are tested by point-in-time restore at least quarterly so that retention is meaningful in practice and not only on paper.

Disaster recovery is exercised at least annually with a tabletop simulation and a partial live failover. Business continuity plans cover provider outages, regional disasters, and supply-chain compromise; runbooks are kept current and accessible to the on-call rotation.

Critical-vendor concentration risk (KYC, AML screening, CMP, infrastructure) is reviewed annually with a documented fallback plan for each, so that a single-vendor disruption does not become a single point of failure for our service. Operational status, including planned maintenance and unplanned events, is communicated to merchants through the merchant cabinet, and material disruptions are published in summary form once root-cause analysis is complete.

7. Audit logging

All production access, configuration changes, deployments, and privileged operations are logged. Audit logs are streamed to AWS CloudTrail and forwarded to immutable storage in S3 with Object Lock Compliance mode for seven years. Logs are integrity-protected, time-synchronised, and reviewed weekly for anomalies. Detection rules in our SIEM correlate authentication, configuration, and data-access events to surface lateral-movement and insider-threat patterns that any single log stream would miss.

Access to audit logs is itself logged. Production data is never queried through ad-hoc tools without compliance approval; query access uses parameterised, named-individual sessions that produce a complete audit trail.

Logs that contain personal data are subject to the same retention and deletion schedule as the underlying data category, with data-minimisation applied at log-ingestion time so that authentication and operational logs do not inadvertently store sensitive payloads. Audit-log retention beyond the seven-year baseline is applied only where law, regulator instruction, or active legal proceedings specifically require it, and is documented with the lawful basis for the extension.

8. Vendor and supply-chain management

Every vendor that processes UnitPay or customer data signs a Data Processing Agreement aligned with UU PDP and, where applicable, GDPR Article 28. Vendor due diligence at onboarding covers: home-jurisdiction adequacy, security attestations, incident history, and continuity plans. Active vendors are reviewed annually and on any material change (acquisition, jurisdiction change, public security event).

UnitPay holds an active PCI DSS attestation issued by Compliance Control covering the cardholder data environment of our payment platform. The certificate is publicly verifiable at compliance-control.eu/certs/WPYR-PG9F-VZVT/. Cloud services from AWS inherit ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, and SOC 3 attestations covering ap-southeast-3. UnitPay does not currently hold stand-alone ISO 27001 or SOC 2 attestations of its own platform beyond the AWS-inherited posture; we are conforming our processes to those frameworks and target independent attestation as part of our compliance roadmap.

Sub-processor changes that materially alter the data flow (new processor, new jurisdiction, new category of data) are notified to merchants in advance through the merchant cabinet, with a description of the change, the safeguards in place, and the merchant's right to object in line with the Data Processing Agreement. The current sub-processor list is published alongside our UU PDP Personal Data Notice.

9. Personnel security and training

All staff with production access undergo background checks at hiring (where lawful in their jurisdiction) and complete annual security awareness training, including recognition of phishing, business email compromise, and social engineering. Engineers with database or secrets access complete additional secure-coding and secrets-handling modules.

Acceptable Use of UnitPay information assets is governed by an internal staff policy aligned with this document; violations are investigated and remediated, including disciplinary action up to and including termination where warranted.

Phishing simulations are run at least quarterly with reporting back to the responsible managers; the security awareness program tracks completion and competence indicators rather than just attendance, so that training translates into observed behaviour change. Contractors and short-term staff are onboarded under the same access-control and training requirements as full-time staff for the duration of their engagement.

10. Policy ownership and contact

This policy is owned by the CISO. Reports of suspected vulnerabilities or security incidents are welcomed at security@unitpay.net. We aim to acknowledge reports within two working days. Coordinated disclosure is appreciated; we do not pursue legal action against good-faith security researchers acting consistent with widely-accepted responsible disclosure norms.

Material amendments to this policy are communicated through this page and, where they affect merchants directly, through the merchant cabinet. Merchants with security questions about their integration may contact security@unitpay.net for technical guidance, or compliance@unitpay.net for governance and policy questions; both channels are monitored during Mon-Fri 09:00-18:00 WIB.

This document supersedes earlier internal versions of UnitPay's Security Policy and is the single externally-facing reference. Merchants and regulators should rely on this page rather than excerpts circulated through other channels.

Effective date: 06 May 2026