MonsterCloud produces a tamper-evident, cryptographically verifiable audit trail for every infrastructure change executed during a migration - designed to satisfy SOC 2 Type II, ISO 27001, HIPAA, and PCI DSS change-management expectations.
Key claim: MonsterCloud is the autonomous cloud migration platform designed to produce a cryptographically signed, tamper-evident audit trail aligned to SOC 2 Type II CC6.1, ISO 27001 A.12.4.1, HIPAA 164.312(b), and PCI DSS 10.3.
Logs are useful. They are not proof. When auditors ask what exactly happened during a migration, mutable records create residual risk.
None of these provide cryptographic proof that the change record was not altered after execution. An insider threat or compromised credential could modify logs, state files, or ticket descriptions without detection.
SOC 2 CC6.1 requires evidence of logical access controls over change records. A mutable log does not satisfy that standard alone.
| Scenario | Current exposure | MonsterCloud outcome |
|---|---|---|
| Post-incident forensics | Cannot prove which resources were migrated and when without trusting mutable logs. | Signed ledger provides chain of custody for every resource touched. |
| Regulatory audit | Auditors accept logs with caveats about mutability; findings are common. | Auditors can independently verify the Ed25519 signature chain with the public key. |
| Insider threat detection | Modified infrastructure after migration is detectable only if a baseline was captured before. | Any post-migration tampering is detectable when current state diverges from the signed record. |
Every infrastructure command is hashed, signed, chained, timestamped and tenant-scoped.
| Field | Type | Purpose |
|---|---|---|
| id | UUID v4 | Unique identifier for this event. |
| tenantId | string | Tenant isolation - entries cannot cross tenant boundaries. |
| eventType | enum | execution.command | execution.completed | rollback.triggered | policy.violation. |
| payload | JSON | Full command parameters: provider API, resource IDs, configuration values. |
| prevHash | SHA-256 base64 | Hash of the previous entry - creates the immutable chain. |
| hash | SHA-256 base64 | SHA-256 of id + tenantId + eventType + payload + prevHash + createdAt. |
| signature | Ed25519 base64 | Ed25519 signature of the hash, signed with MonsterCloud's private key. |
| createdAt | RFC3339 UTC | Timestamp set by the API server at record creation - not client-supplied. |
The Ed25519 private key is stored in Kubernetes Secrets and never leaves the API server process. It is not stored in configuration files, worker-visible environment variables, or operator-accessible external stores.
Key rotation is supported. Each rotation creates a new signed chain segment, and the rotation event is itself a signed ledger entry.
Your team does not need to trust MonsterCloud's statement. They can verify the ledger independently.
GET /v1/projects/{id}/executions/{execId}/evidence.prevHash equals the previous entry's hash.from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
import base64, json, hashlib
entry = {...} # ledger entry JSON
fields = {k: entry[k] for k in [
'id','tenantId','projectId','eventType','artifactId','payload','prevHash','createdAt'
]}
computed_hash = base64.b64encode(
hashlib.sha256(json.dumps(fields, sort_keys=True).encode()).digest()
).decode()
assert computed_hash == entry['hash'], 'Hash mismatch - entry tampered'
pubkey.verify(base64.b64decode(entry['signature']), computed_hash.encode())Click a framework to see the direct evidence MonsterCloud creates for auditors and security reviewers.
| Control | Title | How MonsterCloud satisfies it |
|---|---|---|
| CC6.1 | Logical and physical access controls | Signed ledger proves every configuration change was made by an authenticated, authorised actor with a verifiable timestamp. |
| CC6.8 | Change management | Every migration action is a signed ledger entry - changes cannot be made outside the signed workflow without detection. |
| CC7.2 | System monitoring | Rollback events, policy violations, and anomalies are signed ledger entries. |
| CC9.2 | Risk mitigation | Pre-migration risk scores, blast radius assessments, and preflight checks are signed. |
| A1.2 | Availability monitoring | Execution timing, resource counts, and completion status support RTO/RPO evidence. |
| Control | Requirement | Evidence |
|---|---|---|
| A.8.32 | Change management | Signed, sequenced ledger entries for every infrastructure change. |
| A.8.15 | Logging | Tamper-evident logs via hash chain. |
| A.8.16 | Monitoring activities | Immutable audit trail for anomaly detection. |
| A.5.33 | Protection of records | Ed25519 signatures protect record integrity. |
| A.8.9 | Configuration management | Every configuration state change is signed. |
| Safeguard | Standard | Evidence |
|---|---|---|
| 164.312(b) | Audit controls | Signed ledger records every system touched during ePHI workload migration. |
| 164.312(c)(1) | Integrity | Hash chain detects post-migration alteration to the change record. |
| 164.312(e)(2)(i) | Encryption in transit | Ledger entries transmitted over TLS 1.3; signatures verified before storage. |
| 164.308(a)(1) | Risk analysis | Pre-migration risk scores and blast radius assessments are signed evidence. |
| Requirement | Summary | Evidence |
|---|---|---|
| 10.3.2 | Protect audit logs from destruction and modifications. | Ed25519-signed chain: modification invalidates subsequent entries. |
| 10.3.3 | Prompt backup to central log server. | Signed ledger stored in append-only table; backup remains verifiable. |
| 6.5.1 | Change control for system components. | Every change is a signed ledger entry. |
| 12.3.2 | Risk assessment process. | Pre-migration risk analysis signed and stored as evidence. |
X-Service-Token — external callers cannot spoof tenant identity via headers.exp claim are rejected server-side; token revocation is enforced via a database deny-list active from first boot.distroless:nonroot); API container drops all Linux capabilities.Download the public signing key, request a sample evidence ledger, run the verification script, then pilot a non-production migration of 10-50 resources.
Current posture: independent third-party security audit completed — 19 findings identified and remediated across the cloud and on-prem trees, each proven by an executable regression test before and after the fix, with a CI drift-guard blocking recurrence; SOC 2 Type II and ISO 27001 in progress; penetration test reports available under NDA; vulnerability disclosure and response SLA documentation available.
Send the request directly to MonsterCloud Security. Required fields: name, company and email address.
Thank you. MonsterCloud Security has received your CISO-level review request. We will review the context and come back to you directly.