| name | iso27001-sgsi |
| description | ISO 27001/SGSI — CIA triad, controls, risk assessment. |
ISO 27001 / SGSI / CIA Triad
CIA Triad
The three foundational properties of information security. Every security decision must be evaluated against all three.
| Pillar | Definition | Software implications |
|---|
| Confidentiality | Information is accessible only to authorized parties | Encryption at rest and in transit, access control, least privilege, no PII in logs |
| Integrity | Information is accurate and has not been tampered with | Input validation, checksums, audit logs, signed tokens, immutable audit trails |
| Availability | Systems and data are accessible when needed | Rate limiting, DDoS mitigation, backups, graceful degradation, health checks, SLAs |
When a control improves one pillar, check that it does not degrade another (e.g., aggressive rate limiting improves availability against DDoS but may harm legitimate users — balance required).
SGSI — Information Security Management System
An SGSI (Sistema de Gestão de Segurança da Informação / ISMS) is the framework of policies, processes, and controls that an organization uses to manage information security risk systematically.
Core cycle (Plan–Do–Check–Act):
| Phase | What happens |
|---|
| Plan | Define security scope, conduct risk assessment, set objectives and controls |
| Do | Implement selected controls (technical, operational, organizational) |
| Check | Monitor, audit, measure effectiveness of controls |
| Act | Review findings, apply corrective actions, improve continuously |
For software teams, this translates to:
- Threat modeling before building features that handle sensitive data
- Risk register maintained and reviewed each sprint or quarter
- Security review gate before production deployments (enforce via CI/CD)
- Incident response plan documented and tested
- Security training for all engineers handling customer data
ISO 27001 — Software-Relevant Controls (Annex A)
Focus on the controls most directly actionable by a development team:
A.8 — Asset Management
- Classify data by sensitivity (public / internal / confidential / restricted)
- Document which services process which data classifications
- Define retention and disposal policy for each classification
A.9 — Access Control
- Principle of least privilege: roles grant minimum permissions to accomplish the task
- Privileged access (admin, prod DB) requires MFA + audit logging
- Access rights reviewed quarterly; revoked immediately on offboarding
- No shared credentials — every system actor has a unique identity
A.10 — Cryptography
- Encryption in transit: TLS 1.2 minimum; TLS 1.3 preferred
- Encryption at rest: AES-256 for confidential and restricted data
- Key management: keys stored in a secret manager (AWS KMS, HashiCorp Vault, GCP KMS); never hardcoded
- Password hashing: bcrypt (cost ≥ 12), Argon2id, or scrypt — never MD5, SHA-1, or unsalted SHA-2
A.12 — Operations Security
- Change management: all production changes go through a review process (PRs, approvals)
- Malware protection: dependency scanning, container image scanning in CI
- Logging and monitoring: audit logs for authentication, authorization decisions, data access, and admin actions
- Log retention: minimum 90 days hot, 1 year cold (adjust to regulatory requirements)
A.13 — Communications Security
- Network segmentation: databases not directly reachable from the internet
- API security: authentication required on all endpoints; no unauthenticated data exposure
- Data transfer: PII/sensitive data transferred only over encrypted channels; no email attachments for sensitive data
A.14 — System Acquisition, Development, and Maintenance
- Security requirements defined before development starts (threat model)
- Secure coding standards enforced (OWASP Top 10, this skill set)
- Security testing in CI: SAST, dependency audit, secret scanning
- Separation of environments: dev/staging/production strictly isolated; no production data in dev/staging
A.16 — Incident Management
- Incident response plan: defined roles, communication channels, escalation path
- Security incidents logged and post-mortemed
- Breach notification: know your legal obligation (LGPD: 72h to ANPD; GDPR: 72h to DPA)
A.18 — Compliance
- Legal requirements identified: LGPD, GDPR, PCI-DSS, HIPAA — whichever apply to the project
- Privacy by design: collect minimum data, document purpose, implement erasure
- Regular compliance audits against applicable regulations
Risk Assessment Checklist (per feature / per sprint)
Ask these before building any feature that handles user data or system access:
Audit Log Requirements
Every audit log entry must capture:
| Field | Description |
|---|
timestamp | ISO 8601, UTC |
actor_id | Authenticated user/service identity |
action | What was done (order.created, user.login, admin.permission_granted) |
resource_type | Object type affected |
resource_id | Object ID affected |
outcome | success or failure |
ip_address | Client IP (where applicable) |
user_agent | Client context (where applicable) |
Audit logs must be:
- Append-only (no update or delete)
- Stored separately from application logs
- Tamper-evident (hash chaining or write to immutable storage)
- Retained per regulatory requirement (minimum 1 year)
