A cloud account can pass a review in March and drift out of shape by June. Agnotic Technologies hardens AWS, Azure and Google Cloud accounts against CIS Benchmarks, triages posture findings by real risk and writes controls as policy as code, so evidence for HIPAA, PCI DSS or SOC 2 readiness comes from the pipeline instead of screenshots.
Trusted by global innovators
Cloud security engineering
Cloud security and compliance services configure, monitor and evidence the controls that protect workloads on AWS, Azure and Google Cloud. Agnotic Technologies sets CIS Benchmark baselines, designs identity, key management and central logging, triages posture findings and writes controls as policy as code mapped to NIST SP 800-53, PCI DSS, SOC 2 and HIPAA.
The work is engineering, not paperwork. Every control is a setting, a policy or a pipeline check that can be tested, and every audit question points to the evidence that check produces.
Agnotic does not issue certifications or audit reports. We build the controls and the evidence that your auditor or assessor examines.
Shared responsibility
The provider secures the cloud itself. What you secure depends on the services you pick, and that split decides which controls we build.
Example: Virtual machines on Amazon EC2, Azure Virtual Machines or Compute Engine
Approach: You own the guest operating system, its patches, host firewalls and the software on it. We set hardened images, patch automation and host-level logging.
Example: Managed Kubernetes, managed databases and app hosting services
Approach: The provider runs the control plane or engine; you own configuration, network exposure, identity and data. We baseline the settings and watch for drift.
Example: Functions, managed queues and event buses
Approach: Little to patch, but permissions, event sources and secrets are yours. We scope each function's role and log every invocation path.
Example: File sharing, email and CRM tools used by the business
Approach: Mostly the vendor's, apart from users, sharing settings and retention. We include these tools only where they hold in-scope data.
Findings triage
A posture tool can return a long list of findings on its first scan. Fixing them in the order they appear wastes weeks. This is the order we use.
List the accounts, subscriptions and projects that hold in-scope data, and tag them so findings can be filtered.
Public storage, open management ports, unused access keys and root or owner accounts without MFA go to the top.
Over-broad roles, cross-account trust and long-lived keys that would let one leak reach sensitive data.
Unencrypted stores, keys without rotation and accounts that do not send audit logs to the central archive.
Accepted risks are suppressed with an owner, a reason and a review date, never silently.
Each class of finding we fix becomes a policy that blocks or flags it at deploy time.
Control mapping
We build each control once and map it to every framework in scope. The last column is evidence the cloud or the pipeline produces, not a screenshot.
| Engineering control | NIST SP 800-53 Rev. 5 | HIPAA Security Rule | Evidence produced |
|---|---|---|---|
| Encryption at rest with customer managed keys | SC-28, SC-12 | 164.312(a)(2)(iv) | Key policies, rotation settings and a policy check that rejects unencrypted storage |
| MFA and least-privilege access | IA-2, AC-6 | 164.312(d), 164.308(a)(4) | Identity provider MFA policy, role definitions and access review exports |
| Central audit logs | AU-2, AU-6, AU-9 | 164.312(b) | An organization-wide trail or log export, an immutable archive and alert rules |
| Network segmentation | SC-7 | 164.312(e)(1) | Network definitions in code and a policy check for open ingress |
| Secure configuration baselines | CM-6 | 164.308(a)(1)(ii)(B) | CIS Benchmark results from the posture service, tracked over time |
| Backup and restore tests | CP-9, CP-4 | 164.308(a)(7)(ii)(A) and (D) | Backup policies and dated restore test records |
The mapping is a starting point for your assessor, not a statement of compliance. The final mapping depends on your scope and on their reading of each requirement.
Controls that sit under every workload, set once and enforced everywhere.
Single sign-on to cloud consoles, MFA everywhere, no long-lived access keys and break-glass accounts that alert when used.
Customer managed keys in AWS KMS, Azure Key Vault or Cloud KMS, with separate keys per data class and rotation turned on.
Audit logs from every account, subscription and project sent to one archive that workload teams cannot alter or delete.
Benchmark checks turned on in the posture service, with each exception recorded against the control it affects.
Private endpoints for managed services, no default public ingress, and egress through inspected paths where the data requires it.
Threat detection turned on across accounts, with alerts routed to the people on call and a runbook for each alert type.
Policy as code writes each control as a rule that the cloud or the pipeline checks automatically, so evidence is produced every day instead of gathered before an audit. We use the native engines: AWS Config rules and conformance packs, Azure Policy and Google Cloud organization policies.
Preventive rules block a change, such as a storage bucket made public or a database created without encryption. Detective rules flag drift that slipped through, with automatic remediation where it is safe.
The same rules run in the infrastructure pipeline before a change is applied, so most violations never reach the account.
Results are exported on a schedule to the evidence store your auditor reads, with the rule, the resource and the date on each record.
Failure points
Challenge
Controls were set by hand in the console and nobody can say when they changed.
Agnotic approach
Controls kept in infrastructure code and policy, with every change reviewed and recorded in Git.
Challenge
New accounts or projects start outside the guardrails.
Agnotic approach
Policies applied at the organization or management group level, so new accounts inherit them when they are created.
Challenge
The posture dashboard is full of findings nobody owns.
Agnotic approach
Each finding routed to the team that owns the resource, with response targets by severity.
Challenge
Evidence is a folder of screenshots taken the week before the audit.
Agnotic approach
Scheduled exports of policy results, configuration snapshots and access reviews to a dated evidence store.
Challenge
Each framework has its own spreadsheet of controls.
Agnotic approach
One control set mapped to every framework in scope, so one fix closes the gap everywhere.
Cloud controls and evidence that answer customer reviews and prepare for a SOC 2 examination.
Segmented cardholder data environments with logging and key management built to PCI DSS requirements.
Cloud controls mapped to HIPAA Security Rule safeguards. Day-to-day operations under a BAA sit with our cloud managed services for healthcare.
Cloud security and compliance services for startups usually start with a clean account structure and policy as code before the workload grows.
A long list of findings triaged, fixed in order and turned into rules that stop them coming back.
Frameworks
Agnotic maps and evidences controls against these frameworks; it does not certify against them.
Scope and cost
We do not publish prices. These are the factors we size on the scoping call.
Each one needs baselines, logging and policies, though organization-level policies cut the repeat work.
Each provider has its own policy engine, key service and logging model to configure.
Each extra framework adds mapping and evidence work, though most controls are shared.
A clean landing zone needs guardrails; an older estate needs triage and fixes first.
Some fixes, such as customer managed keys on existing data, need a migration.
Whether we hand over the evidence pipeline or keep running it with your team.
Provider documentation and NIST publications that shape the baselines, policies and evidence on this page.
AWS is responsible for security of the cloud, the infrastructure that runs its services, while the customer's security in the cloud depends on the services it selects; an IaaS service such as Amazon EC2 leaves the guest operating system and its patches to the customer.
Source: AWS Shared Responsibility ModelNIST SP 800-53 Rev. 5 is a catalog of security and privacy controls for information systems and organizations, and NIST publishes the controls in OSCAL as JSON, XML and YAML.
Source: NIST SP 800-53 Rev. 5AWS Security Hub CSPM supports CIS AWS Foundations Benchmark versions 5.0.0, 3.0.0, 1.4.0 and 1.2.0 as security standards that check an account's configuration.
Source: AWS Security Hub CSPM User Guide: CIS AWS Foundations BenchmarkAn AWS Config conformance pack is a collection of AWS Config rules and remediation actions, written as a YAML template and deployed as one unit to an account and Region or across an organization in AWS Organizations.
Source: AWS Config Developer Guide: conformance packsAzure Policy enforces organizational standards and assesses compliance at scale, with a compliance view down to each resource and policy and bulk remediation for existing resources.
Source: Microsoft Learn: Azure Policy overview
