Secure infrastructure

Secure is a claim.Evidence is the product.

Hardened cloud, tested defences, and the logging and control evidence that turns an assertion into something an auditor, a regulator, or an enterprise procurement team will actually accept.

Request a security review Regulated systems work

Quick answer

Secure infrastructure means two things at once — defences that hold, and the evidence that proves they held. Seypro hardens cloud estates on AWS, Azure and GCP, tests them, and produces the audit trail and control documentation required by ISO 27001, SOC 2, GDPR and PCI DSS. The same controls run in production on regulated financial infrastructure.

The gap

Most breaches are not exotic. They are configuration.

An over-broad IAM role, a storage bucket that was public for a fortnight, a key that has not rotated since it was issued, logging that was never switched on so nobody can reconstruct what happened. None of that needs a novel exploit — and all of it is customer-side, not the provider's.

Encryption in transit and at rest

TLS 1.3 everywhere, AES-256 at rest, keys rotated on a schedule you can show.

Access control, per resource

Role-based permissions with explicit matrices — not one admin role that everyone inherits.

Comprehensive audit logging

Every state change, every access, every administrative action, attributable to an actor.

Edge protection

DDoS mitigation at the edge with Cloudflare and AWS Shield before traffic reaches origin.

Continuous assessment

Rolling vulnerability assessment and automated scanning wired into the deployment pipeline.

What we build

Hardening, testing, and the paperwork that follows.

The engineering and the evidence are the same engagement. Split them and you get a secure system nobody can certify, or a certificate over a system nobody tested.

Cloud hardening

AWS WAF, GuardDuty and CloudTrail; Azure Sentinel and Defender; GCP Security Command Center. IAM, KMS and secrets configured for production scale rather than for a demo account.

Threat detection & response

SIEM and EDR deployment with real-time alerting, incident-response playbooks that have actually been run, and automated containment for the cases where minutes matter.

Penetration testing

External and internal testing, web application security testing, and network vulnerability scanning — delivered with a prioritised remediation roadmap rather than a 200-page PDF.

Identity & secrets

Role-based access with per-resource permission matrices, key rotation on schedule, and secrets that live in a manager rather than an environment file someone committed in 2021.

Compliance frameworks

GDPR, ISO 27001, SOC 2 Type II, PCI DSS. These are not interchangeable — each changes the controls, the evidence, and how much audit work lands on your team.

Incident diagnosis

When something goes wrong, every hour of ambiguity has a cost. We diagnose at the source-code level rather than restarting services and hoping it clears.

Frameworks and standards we work to

OWASP ASVS
NIST CSF
CIS Controls v8
ISO 27001
SOC 2
PCI DSS
GDPR
POPIA

Production record

Zero critical incidents across 18+ months in production on a national securities exchange serving 135 jurisdictions — with ISO 27001-aligned controls, penetration testing before every major release, and audit logging on every administrative action.

MERJ Exchange — the case studyNational securities exchange · 135 jurisdictions

Questions

Straight answers.

Do you do penetration testing or compliance, or both?

Both, and they are related. A test tells you what is broken; the compliance work turns the fix into evidence a framework will accept. Doing one without the other leaves you either insecure or unable to prove that you are not.

Can you get us SOC 2 or ISO 27001 certified?

We do the engineering and the evidence preparation. The certificate itself comes from an accredited auditor or certification body — nobody who builds your controls can also sign off on them, and you should be wary of anyone claiming otherwise.

We are on AWS. Is that enough?

The provider secures the platform; you remain responsible for what you configure on top of it. Most incidents we see trace to IAM breadth, public storage, unrotated keys, or logging that was never enabled — all customer-side.

What does an engagement start with?

A review: what you run, how it is configured, what is logged, and which framework you actually answer to. That produces a prioritised list. You are free to take that list elsewhere.

One next step

When did someone last try to break in on purpose?

If the honest answer is never, or not since the last rewrite, that is where we start. Senior engineer on the first call — no sales layer.

Request a security review The full security practice