Skip to content
AfriGRC
Book a Demo
SEC.00 / SECURITY & TRUST CENTRE

Security, privacy, and governance you can verify — not just take our word for.

How AfriGRC approaches security, privacy, resilience, and responsible AI — for the CISOs, privacy officers, auditors, and procurement teams who need to know before their organization does.

Book a DemoTalk to Security
ISO 27001ISO 42001ISO 27701

In-region hosting — illustrative

EgyptNigeriaGhanaKenyaRwandaSouth Africa
SEC.01 / TRUST OVERVIEW

Five commitments the platform is built on.

Not a claim made once on this page — the same five commitments the Security Architecture, Data Protection, and Responsible AI sections below evidence in detail.

  • Security by Design

    Security requirements are scoped before a feature is built, not retrofitted after — encryption, access control, and audit logging are architectural defaults, not add-ons.

  • Privacy by Design

    Data minimisation and purpose limitation are design constraints on every feature, not a policy layered on top after launch.

  • Compliance by Design

    Controls are mapped to the frameworks they satisfy from the first line of the control's definition, so evidence and compliance mapping are never reconstructed after the fact.

  • Responsible AI

    Every AI-generated answer on the platform links back to the control or evidence record it drew from — evidenced automation, never a black box.

  • Enterprise Architecture

    Multi-entity, role-based, and built to scale from a single team to a banking group, on the same architecture underneath every tier.

SEC.02 / SECURITY ARCHITECTURE

Select a domain to see how it's built.

An architectural overview, not an implementation manual — illustrating what exists and why, without exposing sensitive configuration detail.

Authentication

Every account authenticates through a single, centrally managed identity layer — no shadow logins, no shared credentials.

  • Credential verification on every session, not just at signup
  • Session expiry enforced by inactivity and by policy
  • No password ever stored or transmitted in plain text
SEC.03 / DATA PROTECTION & PRIVACY

Personal data, handled to a documented standard.

Principles, not promises about a specific legal outcome — see your organization's Data Processing Agreement for the terms that govern your account.

  • Personal Data Handling

    Personal data is processed only for the purpose it was collected for, under a documented lawful basis.

  • Data Minimisation

    Only the data a feature genuinely needs is collected — nothing gathered speculatively for later use.

  • Data Retention

    Data is retained only as long as its purpose or a legal obligation requires, then scheduled for deletion.

  • Data Deletion

    Deletion requests are honored on a documented schedule, and customer data is deleted per the retention terms agreed at contract when a relationship ends.

  • Encryption

    The same encryption-at-rest-and-in-transit standard from Security Architecture above applies to every category of personal data.

  • Customer Ownership

    Customer data belongs to the customer — exportable on request, and deleted on exit per the retention schedule agreed at contract.

  • Privacy Principles

    Purpose limitation, transparency, and accountability apply to how AfriGRC operates as a company, not only to what the platform sells.

  • Cross-border Data Considerations

    Data residency and cross-border transfer are customer-controlled decisions, documented per jurisdiction rather than defaulted silently.

  • Responsible AI Data Handling

    Data used by AI features is scoped to the same purpose-limitation rules as the rest of the platform — no customer data trains a shared model without an explicit agreement.

SEC.04 / COMPLIANCE ALIGNMENT

AfriGRC's own alignment, framework by framework.

How AfriGRC itself — as a company, distinct from what the platform helps customers achieve — stands against the frameworks it tracks. Filter by category, and open a row for related platform modules and solutions.

  • 11 Aligned
  • 4 In Progress
  • 1 Planned
  • 3 Not Applicable

African Regulations

International Standards

Industry Frameworks

SEC.05 / RESPONSIBLE AI

AI that cites its evidence, governed like everything else.

The same evidence-forward standard applied to AfriGRC's own AI systems as the platform applies to a customer's controls.

  • Human Oversight

    Every AI-assisted output is reviewable and reversible by a person — no AI action is final without a human able to inspect it.

  • Explainability

    Every AI-generated answer links back to the control or evidence record it drew from, not a black-box conclusion.

  • Transparency

    Where AI is used on a page or in a workflow, it is stated plainly — never presented as if a person produced it unaided.

  • Bias Awareness

    AI features are reviewed for skewed outcomes across the populations and jurisdictions AfriGRC serves, not validated on a single reference market.

  • Secure AI

    AI systems are held to the same access-control, encryption, and logging standard as the rest of the platform — not a separate, less-governed layer.

  • AI Governance

    AI capabilities are inventoried and risk-classified under the same management-system discipline ISO 42001 expects, applied to AfriGRC's own AI systems.

  • Model Monitoring

    Model behavior is monitored in production, not validated once at launch and left unchecked.

  • AI Risk Management

    AI risk is assessed before a feature ships, not discovered after an incident.

  • Auditability

    Every AI-assisted decision leaves a record — what was asked, what was cited, and when — available for review.

SEC.06 / SECURE DEVELOPMENT LIFECYCLE

Security reviewed at every stage, not bolted on at the end.

Nine stages, from planning through continuous improvement. Select a stage for what it specifically covers.

  • 01

    Planning

    Security and privacy requirements are scoped alongside product requirements, not added after the fact.

    Threat considerations reviewed at the design-intake stage

    Data classification decided before a single line of code is written

  • Design review checks against existing control patterns before new ones are introduced

    Data flows mapped before implementation begins

  • Dependency scanning integrated into the development workflow

    Secrets excluded from source control by default, not by convention alone

  • Security-relevant changes flagged for additional review

    Review is a required step in the merge process, not optional

  • Automated test suites run on every change

    Security-relevant paths receive targeted test coverage

  • Risk-based review — not every change requires the same depth

    Findings are tracked to resolution before release, not deferred

  • Deployments are logged and attributable to a specific change

    Rollback path defined before release, not improvised after an incident

  • Anomalous activity flagged for review, not just logged and forgotten

    Monitoring coverage extends to infrastructure and the application layer

  • Post-incident findings become new pipeline checks, not a one-time fix

    The lifecycle itself is reviewed periodically, not treated as fixed

SEC.07 / SECURITY OPERATIONS

How AfriGRC runs security day to day.

Described at the level of practice, not a service-level commitment — specific SLAs are agreed at contract, not asserted here.

TR.01

Incident Management

Security and operational incidents are logged, triaged, and routed to an owner from the moment they're detected.

TR.02

Monitoring

Systems are watched continuously for availability and security signals, not checked periodically.

TR.03

Alerting

Anomalies raise an alert to a named owner — nothing waits for someone to notice it on a dashboard.

TR.04

Business Continuity

Continuity plans are documented and exercised under the same discipline ISO 22301 expects, not written once and filed away.

TR.05

Disaster Recovery

Recovery procedures are defined and tested against a stated recovery objective, not assumed to work when needed.

TR.06

Change Management

Production changes follow a controlled, auditable path from proposal to deployment — see Secure Development Lifecycle above.

TR.07

Vulnerability Management

Known vulnerabilities are tracked and remediated on a risk-based timeline, not left for the next audit to surface.

TR.08

Risk Management

Operational risk is assessed continuously, feeding the same risk-register discipline AfriGRC's own platform is built to provide customers.

SEC.08 / SECURITY REVIEW CHECKLIST

What a procurement review usually asks for.

Tick what your organization needs to confirm — each reveals where on this page (or elsewhere on the site) the answer already lives. Nothing here claims a completed certification; check Compliance Alignment above for AfriGRC's actual status.

Security

Privacy

Compliance

Architecture

Risk

Operations

0 of 12 areas reviewed

Tick an item to reveal what to have ready for that area — nothing here is submitted anywhere.

SEC.09 / TRUST RESOURCES

Documentation for your own review.

Most of what's below isn't published yet — request it directly rather than waiting for a public release.

  • PDF whitepaper

    Security Whitepapers

    A structured overview of AfriGRC's security architecture, written for a security team's own review.

    Not yet published — request below

  • Technical guide

    Architecture Guides

    Deeper technical detail on how the platform is built — for architecture and infrastructure teams evaluating a rollout.

    Not yet published — request below

  • Policy document

    Privacy Documentation

    AfriGRC's own data handling and privacy commitments, distinct from the Privacy Policy that governs the marketing site.

    Not yet published — request below

  • Compliance pack

    Compliance Documentation

    Control mappings and evidence summaries formatted for a procurement or audit review.

    Not yet published — request below

  • Governance document

    Responsible AI Documentation

    AfriGRC's AI governance approach, model oversight practices, and how ISO 42001 principles are applied internally.

    Not yet published — request below

  • FAQ

    Security FAQs

    Answers to the security questions procurement and audit teams ask most often.

    See the FAQ below →
SEC.10 / DOCUMENT REQUEST PORTAL

Request documentation directly.

No document library to browse yet — tell us what you need and who you are, and it's routed to the right person.

Step 1 of 2

What do you need?

Select everything relevant — one request covers all of it.

Documentation requested
SEC.11 / SECURITY FAQ

Security Frequently Asked Questions.

SEC.12 / CONTACT SECURITY TEAM

Reach the right person directly.

  • Contact Security

    Reach the security team directly for a specific technical or architecture question.

    Email Security

  • Request Security Information

    Request AfriGRC's security documentation, architecture guides, or compliance pack.

    Request Documents

  • Book Technical Review

    Schedule a technical session with AfriGRC's security and solutions engineering team.

    Book a Demo

  • Sales Security Questionnaire

    Send your organization's security questionnaire for the sales and security teams to complete.

    Send Questionnaire
SEC.13 / GET STARTED

See AfriGRC's posture matched against your own requirements.

A live technical review, or a direct line to security — whichever your process needs next.

Book DemoContact SalesTalk to Security
Security & Trust Centre — AfriGRC