ISO 27001/27701 Compliance: What It Takes to Get Certified

By Laura Daly, Security Risk and Controls Manager

When we decided to pursue dual ISO 27001 and ISO 27701 certifications for Flo, I knew what we were getting into. I’d done all of this before at previous organizations, but the real test of how difficult certification will be is how prepared your company is. 

ISO audits are a lot of work, but they also provide valuable insights that can strengthen your security posture and build confidence in your controls. But it’s one thing to do the work day to day, but it is another to gather evidence of that work, and to build and maintain an audit-ready framework. 

Flo became the first femtech app certified to both ISO 27001 (Information Security Management) and ISO 27701 (Privacy Information Management). The process took significant time and involved our entire organization.  But it does not simply end with achieving the certification. Maintaining it is a core consideration in everything we do–from new product features to HR processes or marketing communications. Privacy and security must be embedded into all our processes and require ongoing efforts from everyone at Flo, every day.

Let me walk you through what ISO certification actually requires from an engineering perspective, and what we learned along the way that could help other organizations prepare to start their own ISO journey. 

What ISO Certification Means

ISO 27001 defines requirements for an Information Security Management System (ISMS). It's not a checklist of "install firewall” or “enable encryption." It's a layered, systematic approach to managing security across your entire organization. ISO 27701 extends ISO 27001 with privacy-specific requirements, aligned with GDPR and other privacy regulations.

Together, they define controls across multiple domains. Every control requires:

1. A documented policy explaining what you do
2. Technical implementation proving you actually do it
3. Evidence showing it works
4. Continuous monitoring, ensuring it keeps working

Auditors verify all four. They read your policies, test your systems, interview your engineers, and verify that reality matches your documentation. Not only did our team meet the requirements of certification, but we won the 2025 PICASSO Team of the Year award for our work to meet this standard.

The ISMS: Core Architecture

The foundation for all of this is the Information Security Management System. 

Here's a generic risk assessment framework to illustrate what that looks like. Feel free to tailor this for your own organization if it’s helpful!

After assessing the risks, prioritize them by score, and implement controls for anything scoring above your risk tolerance threshold.

For example:

Risk: Unauthorized access to production database

• Asset: User health data (high impact)
• Threat: External attacker or malicious insider
• Required controls: JIT access, audit logging, encryption

Each identified risk drives concrete technical requirements.

Annex A: Access Control & Privileged Access

Let's dive into specific controls, starting with access control.

Annex A: Access Control Implementation (5.15, 5.18, 8.2)

We documented a formal access control policy and enforced it technically through our infrastructure-as-code systems. Our access policies are defined declaratively and enforced automatically through IAM (Identity and Access Management) systems.

The key principles cover:

• Default deny: Access is denied unless explicitly granted
• Just-in-time access: No standing privileges; access is granted on demand
• Privileged access: Approval-based with layered authorisation (e.g., line manager and senior approval) and is granted only when justified for a specific task.
• Time limits: Access is time-bounded and removed when no longer required. 
• Audit logging: Access provisioning/changes and access activity (especially privileged access) are logged, and access logs are protected from unauthorized removal or modification.
• Access reviews: Access rights are reviewed on a defined cadence. 

These policies are technically built into our infrastructure to prevent bypass.

Control A.8.2 Privileged Access Rights

We implemented Just-In-Time (JIT) privileged access for all production systems. Engineers don't have standing access to production databases, customer data, or sensitive systems. Instead, when they need access for a specific task, they request it through an automated workflow following the policy above and we enforce step-up authentication for privileged access (hardware-backed MFA for high-risk environments such as AWS).

Annex A: Cryptography 

Control 8.24 Use of Cryptography 

Our cryptography & Key Management Policy defines the mandatory cryptographic standards and required implementations used to protect sensitive and business‑critical information (confidentiality, integrity, and authenticity), and to prevent weak or outdated cryptography being introduced.

Approved algorithms include:

• Symmetric encryption: AES-256-GCM exclusively
• Asymmetric encryption: RSA (2048/4096) and Ed25519 with SHA‑256. 
• Digital signatures: Ed25519 with SHA‑256 (per approved standards).
• Minimum key sizes/standards: defined by the approved algorithm set (e.g., AES‑256; RSA 2048/4096).

Required implementations include:

• Transport security: TLS 1.2 minimum, with TLS 1.3 preferred; weaker protocols are prohibited for external‑facing services.
• Encryption at rest: AES‑256 is required for cloud storage and databases; databases also require TDE, and field‑level encryption is required for highly sensitive data.
• Email security: TLS 1.2+ plus anti‑spoofing controls (SPF, DKIM, DMARC).
• Endpoints/removable media: full‑disk encryption (e.g., FileVault) must be enforced; removable media use is limited and must be encrypted if used.

At Flo, we enforce these requirements through multiple mechanisms:

• Code review: Every cryptographic change requires security team approval
• Automated scanning: CI/CD pipelines check for weak algorithms and reject code that uses them
• Linting rules: Static analysis tools flag uses of deprecated or weak crypto
• Library restrictions: Only approved, well‑vetted libraries/modules may be used for cryptographic implementations. 

We enforce minimum cryptographic standards through policy-defined requirements, Security governance/exception handling, and required secure implementation practices (including the prohibition of weak transport protocols for external-facing services). 

Control 8.24: Cryptographic Key Management

All cryptographic keys used to protect sensitive or business‑critical information must be managed across their lifecycle, and stored in an approved secure location such as a Key Management Service (KMS), Hardware Security Module (HSM), or encrypted key vault (not “HSM-only”). Our key management approach includes:

• Key Generation: Keys must be generated using cryptographically secure random number generators (CSPRNGs) and approved algorithms, and key generation must ensure key material is not exposed to unauthorised systems or personnel. 
• Key Storage & Protection: Keys must be stored in an approved secure location (KMS/HSM/encrypted vault). Access must be restricted via strict RBAC and require MFA where technically feasible; keys must never be stored in source code, configuration files, or unencrypted storage.
• Key Usage: Access to cryptographic keys must be limited to the minimum number of authorised personnel and systems required for the business function; all key usage operations (e.g., encryption, decryption, signing) must be logged per our Logging and Monitoring Standard to create a verifiable audit trail.
• Key Rotation: Keys must be rotated automatically where technically feasible, at a frequency defined by the Security Team based on the key’s classification and usage; rotation must ensure a seamless transition without service interruption.
• Key Revocation & Destruction: Keys must be revoked immediately if compromise is suspected or confirmed; when a key is no longer required for any business purpose (including data recovery), it must be securely and irreversibly destroyed. 

This lifecycle-based approach supports ISO 27001 expectations by limiting key access, enforcing secure storage controls, ensuring rotation and rapid revocation, and ensuring key operations are auditable via required logging.

Annex A: Logging & Monitoring (8.15, 8.16)

Control 8.15 Logging

Our Security Logging Standard requires hosts and networking equipment to generate security logs for all components capable of producing security‑relevant events, and requires systems that handle confidential information, accept network connections, or make authentication/authorisation decisions to record and retain audit logs sufficient for investigations and forensics.Our audit logging captures:

• Subject identifiers (e.g., user name, system identity, IP/MAC), standardised for correlation.
• Type of action (e.g., authorise, create/read/update/delete, accept network connection).
• Object identifiers (e.g., resource IDs, file names, record identifiers, query parameters).
• Date/time in UTC (and systems maintain clock synchronisation to a common time source).
• Subsystem performing the action (e.g., process/transaction name and identifier).
• Access control status (allowed/denied) and reason codes for denied actions when applicable.
• Before/after values when feasible for updates, and correlation identifiers where supported to enable traceability.

Our Logging Standard requires that security log information is safeguarded against tampering and unauthorised access, and protected in accordance with the highest classification of information the logs may contain (including appropriate encryption, access controls, monitoring, and regular audits).

To support monitoring and investigations, we also require:

• Protection of administrator/operator logs: privileged users must not have permissions to modify, erase, or deactivate logs of their own activities.
• Security log consolidation: security log data must be transferred to consolidated log infrastructure in real time (or as quickly as the technology allows), and entities must establish processes for operating/integrating log management systems.
• Retention: logs must be retained in accordance with our Data Retention Schedule, with sufficient storage capacity planning for both readily available and retained logs.

For consolidated log infrastructure, log integrity must be preserved (e.g., write‑once media or per‑log‑file message digests), with controls to protect against alteration of event messages, editing/deletion of log files, and storage capacity issues that could overwrite or prevent recording of events.

Access to log management systems must be recorded and limited to individuals with a specific need, and access to log data must be limited to the specific datasets appropriate for the business need.

Control 8.16 Monitoring Activities 

Flo’s monitoring is supported by the logging requirements above: security log data is consolidated (real time where possible) so it’s available for security monitoring, incident response, and forensic investigations.

Control A.8.27 Secure System Architecture and Engineering Principles

We enforce security throughout our development lifecycle through Flo’s Secure Software Development Lifecycle (SSDLC), aligned to DevSecOps and CI/CD, with a focus on “shifting left” risk identification and mitigation across each iteration.The SSDLC defines secure coding and verification activities that are expected during development and before release, including:

• Static Analysis: Security-focused code review and automated security static analysis (SAST) are used to identify security weaknesses; code review is performed by a senior developer and references SSDLC guidelines and OWASP Top 10.
• Dependency Scanning: Dependency analysis / software composition analysis is required, and open-source vulnerability checks are performed as part of the release via automated scans of application dependencies and container images to help prevent deployment of applications with known vulnerabilities.
• Secret Scanning: Automated tools scan for accidentally committed secrets—API keys, passwords, private keys, tokens. If any are detected, the build fails immediately, and the security team is alerted.
• Custom Security Rules: Beyond off-the-shelf tools, we've built custom validators for our specific security requirements. For example, we check that all cryptographic operations use approved algorithms, that PII handling follows our policies, and that database queries use parameterized statements.

The key principle for us is that security checks are mandatory, not advisory. Builds fail if security issues are detected, meaning there's no "merge anyway" option. This creates occasional friction, but it's intentional, preventing known security bugs from reaching production.

Beyond automated checks, we also require:

• Security code review: Every PR touching sensitive code paths requires review from a senior developer prior to check-in to version control or as part of the release process
• Threat modeling: New features undergo threat modeling before implementation
• Security testing: Penetration testing and security assessments for major features

ISO 27701: Privacy-Specific Controls

ISO 27701 adds privacy to security - it enhances security controls to make sure they consider data privacy, and adds further requirements that are specific to the world of data protection. Let’s walk through the key areas covered by ISO 27701. 

• Privacy policies and procedures - How we communicate and maintain our privacy practices
• Consent management - How we obtain and track user consent
• Data subject rights - The processes we have to support and uphold all privacy rights, including access, deletion, and portability requests
• External privacy notices - Ensuring we have clear and transparent privacy practices
• Third-party data sharing - Managing data sharing with third parties (such as service providers who help us run the app)
• Data retention and deletion - Making sure we only keep data when we need it
• Data breach response - Procedures for detecting, managing, and reporting breaches
• Cross-border transfers - Safeguards for permitted international data transfers 
• Privacy training - How Flo employees are trained to uphold our privacy requirements & standards

One tool we use to assess privacy risks is the Data Protection Impact Assessment (DPIA). This is always undertaken before development begins, and systematically evaluates:

• What data is being processed (type, sensitivity, volume)
• Why we need it (purpose, legal basis)
• How it will be processed (systems, flows, retention)
• Who has access (roles, permissions, third parties)
• What risks exist (re-identification, misuse, breach)
• What mitigations we'll implement (technical and organizational measures)

The DPIA process involves multiple stakeholders, including: engineering (to understand technical implementation), product (to clarify requirements), Privacy (to assess compliance), security (to evaluate security risks), and the Data Protection Officer (to approve the final assessment).

The Audit Process

After implementation, the real test comes, which is the third-party audit. Here is a simplified view of the process. 

Stage 1: Documentation Review

Auditors reviewed our policies, procedures, and evidence documents to verify that our documentation covered all required controls.

Stage 2: Technical Testing

The auditors then tested our systems to ensure they worked as stated in our documentation:

• Attempted unauthorized database access (blocked by JIT requirements)
• Checked encryption (verified strong algorithms everywhere)
• Reviewed access logs (confirmed complete audit trail)
• Tested key rotation (verified automated rotation)
• Examined incident response (reviewed our drills and procedures)

Stage 3: Interviews

Auditors interviewed our engineers to verify they really understood our policies and how to implement them, rather than simply reciting them. 

Stage 4: Annual Recertification

Certification isn't permanent. We're audited annually to verify continued compliance.

Conclusion

ISO 27001/27701 certification focuses on building systematic security and privacy into your engineering culture.

It requires:

• Comprehensive risk assessment
• Technical controls (JIT access, encryption, audit logging)
• Automation (key rotation, rights fulfillment, security scanning)
• Documentation (policies, procedures, evidence)
• Continuous improvement (annual audits, ongoing monitoring)

The standards are publicly available. The controls are well-defined, and the audits are rigorous.

If you handle sensitive data (health, financial, personal), ISO certification demonstrates your commitment to protecting it. Not through marketing promises, but through independently verified, systematically implemented controls.

For everyone using Flo, that verification matters. Privacy and security claims backed by third-party certification are worth more than promises.

If you're considering ISO certification, start with a risk assessment to better understand what you're protecting and the threats you face. Then build controls to make those threats impossible or improbable.

The journey is substantial, but the destination is worth it.

Related Resources: 

• Our ISO Certifications 
• Privacy Portal Homepage