D1 · Information security policy
This policy sets the security rules that apply to the Bolívar Connect platform and to all personnel who operate it. The other documents (D2 to D7) build on it.
1. Purpose
Section titled “1. Purpose”To protect the confidentiality, integrity and availability of the information the platform processes. In particular, clients’ payment instructions and beneficiaries’ personal data.
2. Scope
Section titled “2. Scope”It applies to the API, the database, the AWS infrastructure, the code repository, the credentials and all personnel with access to any of them.
3. Principles
Section titled “3. Principles”- Least privilege: each person, service and API key has only the access it needs for its function.
- Defense in depth: no control relies on a single one; network, application and data each have their own protections.
- Secure by default: the platform refuses to start in production with an insecure configuration.
- Data minimization: only the personal data essential to execute the payment is processed.
- Traceability: every relevant action is recorded and attributable to an actor.
4. Roles and responsibilities
Section titled “4. Roles and responsibilities”| Role | Responsibility |
|---|---|
| Management | Approves this policy, allocates resources and accepts residual risks |
| Security Officer (Tech Lead) | Maintains the policy, approves access, coordinates incidents and risk assessments |
| Technical personnel | Comply with the policy, protect their credentials and report any incident or weakness |
| Third parties | Meet the security requirements of document D7 |
5. Controls
Section titled “5. Controls”5.1 Information classification
Section titled “5.1 Information classification”| Level | Examples | Handling |
|---|---|---|
| Restricted | Secrets, API keys, third-party credentials, personal data | Encrypted, minimal access, never in logs or in the repository |
| Confidential | Security findings, infrastructure details, contracts | Authorized personnel only; outside the code repository |
| Internal | Source code, technical documentation | Members of the organization |
| Public | API documentation, security policies, privacy policy | No restriction |
5.2 Access control
Section titled “5.2 Access control”API key authentication with scopes for clients. MFA for infrastructure access. Server administration only through AWS SSM Session Manager, without SSH. The details are in D2.
5.3 Cryptography
Section titled “5.3 Cryptography”- TLS 1.2 or 1.3 on all external communication; TLS 1.0 and 1.1 disabled; HSTS enabled.
- AES-256 encryption at rest with AWS KMS for volumes and backups.
- API keys and access tokens are stored only as SHA-256 hashes.
- Webhooks are signed with HMAC-SHA256, with one secret per client.
5.4 Secrets management
Section titled “5.4 Secrets management”Secrets are stored in AWS Secrets Manager and read through an IAM role limited to the specific secrets. Including secrets in code, in the repository, in logs or in messaging channels is forbidden. An exposed secret is rotated immediately.
5.5 Network security
Section titled “5.5 Network security”Each service has its own security group, with only the necessary ports. The database is not reachable from the internet.
5.6 Secure development
Section titled “5.6 Secure development”Every change passes the automated test suite, including the security tests, before being deployed. Changes that touch authentication, payment instructions or personal data get a security review. Infrastructure is defined as code.
5.7 Logging and monitoring
Section titled “5.7 Logging and monitoring”Each request carries a request_id. Administrative actions are recorded in an
insert-only audit log. Logs do not contain personal data in clear text.
Retention periods are in D6.
5.8 Vulnerabilities, incidents, continuity and third parties
Section titled “5.8 Vulnerabilities, incidents, continuity and third parties”They are governed by D3, D4, D5 and D7 respectively.
5.9 Personnel
Section titled “5.9 Personnel”All personnel sign a confidentiality agreement when joining and receive training on credential handling, phishing and secure development. When they leave, their access is revoked the same day.
6. Risk management
Section titled “6. Risk management”Technology risks are assessed upon every relevant change in architecture, before onboarding a new client or third party, and at least once a year. Each risk is rated by likelihood and impact (high, medium or low) and recorded with its treatment:
| Treatment | When |
|---|---|
| Mitigate | The risk is high or medium and a reasonable control exists |
| Accept | The residual risk is low; Management accepts it in writing |
| Transfer | Through a contract or insurance |
| Avoid | The activity that causes it is eliminated |
7. Reference frameworks
Section titled “7. Reference frameworks”Controls are aligned with ISO/IEC 27001 Annex A, the OWASP Top 10 and the OWASP API Security Top 10. The organization does not claim formal certification.
8. Compliance and exceptions
Section titled “8. Compliance and exceptions”Non-compliance with this policy may lead to removal of access and to disciplinary or contractual measures. Every exception is requested from the Security Officer, approved in writing, has an expiry date and is recorded.
9. Review
Section titled “9. Review”This policy is reviewed once a year, or earlier if the architecture, the third parties or the applicable regulation change.