Skip to content

SolutionsAWS Security Competency Partner

Ship on AWS. Pass the audit.

Guardrails, pipelines and detection built as code around your AWS workloads. Your developers keep shipping; your auditor gets evidence, not screenshots.

Book a 30-minute AWS security review
Figure 1 · Every change passes a scan and a policy gate before an OIDC deploy. A hard-coded key stops at the gate.

Where estates are today

Does your AWS estate look like this?

  • Standing admin rights
  • Static pipeline keys
  • Console changes
  • Findings nobody owns
  • Evidence built by hand
One AWS estate, two shapes

ClickOps estate

One shared AWS account
  • Company accountEverything in one place
    • ProductionShared admin usersNo guardrails
    • TestSame account
    • CI pipelineStatic access key

Governed estate

AWS Organization · Control Tower
  • Management accountOrganizations · SCPs
    • Security organisational unit
      • CloudTrail on
      • Log archive
      • Security tooling
    • Workloads organisational unit
      • No public S3
      • Production (highlighted)
      • Non-production
    • Sandbox organisational unit
      • Budget cap
      • Experiments

How we secure a platform

Four layers, all in code.

Every control lives in your repositories and ships through your pipeline, so the baseline is enforced, not documented.

Secure AWS platform · four views

01 Foundation

guardrails/scp/protect-security-baseline.jsonSCP · JSON+3−1
{  "Sid": "ProtectSecurityBaseline",  "Effect": "Deny",  "Action": [    "cloudtrail:StopLogging",    "cloudtrail:DeleteTrail",Removed:     "guardduty:DeleteDetector"Added:     "guardduty:DeleteDetector",Every OUAdded:     "securityhub:DisableSecurityHub",Added:     "organizations:LeaveOrganization"  ],  "Resource": "*"}
Policy checkguardrails · security baselineFAIL · 2 gaps→PASS · 0 gapsNo account can switch off its own logging or detection.

Guardrails as code: service control policies on every OU that no account can switch off.

02 Pipeline

git push origin feature/deploy-rolePASSbuild      tests and SBOMPASSiac-scan   terraform plan, no high findingsFAILpolicy     static access key in deploy.tf# fix pushed: OIDC deploy role, no stored keyPASSpolicy     no-static-credentialsPASSdeploy     non-prod, short-lived OIDC rolewaiting   approval to promote to prod

Every change is scanned and checked against policy before it reaches an account.

03 Runtime

AWS Security HubEC2.13

Severity: high

Security group allows SSH from 0.0.0.0/0

Resourcesg-0a1b2c · payments-non-prod

  1. 10:02Detected by AWS Config, raised in Security Hub
  2. 10:03Routed to the payments team
  3. 10:21Fix merged: rule removed, Session Manager instead
  4. 10:26Control re-evaluated: passed

ResolvedFixed through the pipeline, with the change on record.

Findings from every account land in one place, each with an owner and a timeline.

04 Evidence

Control coverage · Organization · 12 accountsIllustrative data

Controls passing

91%

Target 95%

Accounts in guardrails

12 / 12

All OUs

Open high findings

3

Each with an owner

Controls mapped by framework · Controls

  • NIS2 · Article 2142
  • DORA · ICT risk38
  • CIS AWS Foundations31
Illustrative numbers, not a client result.

Control coverage mapped to NIS2 and DORA, produced as a by-product of the work.

AWS Advanced Tier Services Partner with the AWS Security Competency

Validated by AWS. Built by certified engineers.

AWS Services Partner
Advanced Tier
AWS service deliveries
8
AWS certifications
25+
AWS certified
Every engineer

Ways to start

Four engagements. You keep the code.

Each has a defined end. What you keep lands in your repositories, not a slide deck.

  1. Entry

    Security baseline review

    Accounts, IAM and pipelines, read against AWS best practice.

    You keep
    • findings-by-risk.md
  2. Build

    Landing zone and guardrails

    Control Tower, SCPs and IAM Identity Center, or a fix of yours.

    You keep
    • landing-zone/
    • account-vending/
    • runbook.md
  3. Build

    Secure delivery pipeline

    Scanning, policy as code and OIDC deploys.

    You keep
    • .github/workflows/
    • policies/
  4. Run

    Posture operations

    Your Security Hub backlog, worked with you in business hours.

    You keep
    • evidence-pack/
    • named engineer

How an engagement runs

Non-production first. Always.

  1. Read-only

    Read the estate.

    Accounts, IAM and pipelines, with your platform team.

  2. Agreed

    Agree the baseline.

    Controls mapped to your NIS2 or DORA scope, each with an owner.

  3. Non-prod

    Build it as code.

    Guardrails and gates land in non-production, through your reviews.

  4. Production

    Promote and hand over.

    Your team runs it, or we run it with you.

Engineers you’ll work with

The people who scope it build it.

Every engineer is AWS certified.

  • Parsectix engineers together at a team evening

    Delivery team

  • Pavlos Kleanthous, founder of Parsectix

    Pavlos Kleanthous · Founder

FAQ

What teams ask us first.

It is an AWS Partner designation awarded after AWS validates a partner’s security practice and customer work. Parsectix is an AWS Advanced Tier Services Partner with the AWS Security Competency.

Yes, most of our work starts there. We read the estate first, then bring it under guardrails account by account, without a big-bang migration.

Checks run in the pipeline, and a failed check says what to fix. Engineers stop waiting for a manual security review at the end.

No. We work alongside them and hand everything over as code. We stay on to run it only if you want us to.

Yes. Parsectix is a Cloudflare partner too, so the edge and the AWS estate are designed as one system, with one accountable team.

Start here

Talk to the engineers who will build it.

Thirty minutes with a senior engineer on your AWS estate.

Book a 30-minute AWS security review