TX-RAMP Level 2 assessment requirements: what hands-on testing finds
Amara OkaforApril 29, 2026
Key takeaways
TX-RAMP Level 2 is based on NIST SP 800-53 Rev 5 Moderate (323 controls) but assessed under Texas DIR evidence standards — not FedRAMP JAB standards. Evidence packages scoped for FedRAMP review routinely fail TX-RAMP assessment because DIR reviewers request different evidence formats, different control narratives, and different continuous monitoring artifacts.
The most consistent finding in Vulnox TX-RAMP Level 2 assessments is hardcoded secrets in application configuration files and environment variable exports — API keys, service account credentials, and database connection strings that exist outside the key management system the compliance evidence package describes.
TX-RAMP Level 2 logging requirements under AU-2 and AU-12 (NIST 800-53 Moderate) specify event capture, but the failure mode is not missing logs — it is logs stored in formats that cannot be queried fast enough to meet TX-RAMP's incident response timeline requirements under IR-6.
Organizations that self-attest logging coverage by showing SIEM dashboards consistently have gaps at the service layer: serverless functions, containerized workloads, and third-party SaaS integrations that emit events outside the SIEM ingestion pipeline (Vulnox assessment data, 2024–2025).
TX-RAMP Level 2 requires continuous monitoring with defined assessment frequencies — quarterly for high-impact controls, annually for the full control set. Most organizations treat continuous monitoring as a SIEM alert configuration exercise rather than a scheduled control re-validation program, which produces a compliance gap that surfaces at the first annual DIR review.
TL;DR
TX-RAMP Level 2 is not FedRAMP Lite and it is not SOC 2 with a Texas accent. It is NIST 800-53 Moderate assessed by a Texas-registered assessor against DIR-specific evidence standards, and the gap between what automated scanning finds and what hands-on testing finds is wide. The two places that gap shows up most consistently are key management — specifically secrets that live outside the key management system — and logging configurations that satisfy retention policy but cannot support incident reconstruction under realistic conditions.
What TX-RAMP Level 2 assessments find that automated scans miss
Assessment base: Vulnox assessment data, 2024–2025, SaaS vendors and cloud service providers seeking TX-RAMP Level 2 authorization
Hardcoded secrets in configuration files and environment variable exports
TX-RAMP Level 2 requires key management controls under IA-5 and SC-12 (NIST 800-53 Moderate). The compliance evidence for these controls typically consists of key management policy documents, KMS configuration screenshots, and vendor attestations. What automated scanning and documentation review do not surface: secrets that live outside the key management system entirely. In Vulnox TX-RAMP assessments, the consistent finding is API keys, database connection strings, and service account credentials stored in application configuration files, .env files, or Docker environment variable exports — not in the KMS the compliance evidence describes. These secrets are not rotated on any schedule. They are not covered by any access control policy. They exist in Git history, in container image layers, and in deployment automation scripts. The compliance evidence is accurate for what it covers. The problem is the population it does not cover (Vulnox assessment data, 2024–2025, SaaS vendors serving Texas state agencies).
An attacker who obtains a configuration file — through a misconfigured S3 bucket, an exposed deployment pipeline, or a compromised developer workstation — has credentials that bypass every KMS control the compliance evidence demonstrates. The key management posture that passed review does not describe the actual credential landscape.
Logging configurations that satisfy AU-2 but fail incident reconstruction
NIST 800-53 AU-2 requires organizations to identify the types of events the system is capable of logging. TX-RAMP Level 2 assessors verify this through logging policy documentation and SIEM configuration evidence. The failure mode is not missing event types in the policy — it is the gap between policy-defined events and events that are actually ingested and queryable. In Vulnox assessments, the most frequent logging gap involves three categories: containerized workload logs routed to stdout but not forwarded to the SIEM ingestion pipeline, serverless function invocation logs sitting in cloud-native log storage that is not connected to the central SIEM, and third-party SaaS integration events that are available via API but have never been configured for ingestion. The compliance evidence shows the SIEM dashboard. The dashboard shows only what is connected to it.
TX-RAMP Level 2 incident response requirements under IR-6 require organizations to report security incidents to DIR within defined timeframes. Incident timeline reconstruction that depends on logs not connected to the SIEM fails silently — the team does not know the gap exists until they need those logs during an active incident. By then the notification window is the constraint, not the investigation.
Continuous monitoring treated as SIEM alerting rather than scheduled control re-validation
TX-RAMP Level 2 requires a continuous monitoring strategy under CA-7 that includes defined assessment frequencies: quarterly for high-impact controls, annually for the full control set. In practice, organizations interpret continuous monitoring as the SIEM alert configuration they already have. The CA-7 requirement is about scheduled re-validation of whether controls are functioning — running the access control test again, re-checking the key rotation execution, re-validating the backup residency configuration. This is a different activity from alert monitoring. In every Vulnox TX-RAMP Level 2 engagement where continuous monitoring was assessed, the organization had a mature SIEM deployment and no documented control re-validation schedule. The two are not substitutes (Vulnox assessment data, 2024–2025).
At the first annual DIR review, the assessor will request evidence of quarterly high-impact control re-validation. An organization that has been running SIEM alerts for 12 months but has not run a single scheduled control re-validation has no evidence to provide. This is not a minor documentation gap — it is a CA-7 control failure that requires remediation before the review can proceed.
FedRAMP-format evidence packages that fail DIR review
TX-RAMP Level 2 shares its control baseline with FedRAMP Moderate — both are NIST 800-53 Rev 5 Moderate. This leads vendors with existing FedRAMP programs to assume their evidence packages will satisfy TX-RAMP assessment with minor adaptation. DIR evidence standards are different in three specific ways: DIR reviewers expect control implementation descriptions written against the Texas state agency use case, not a generic federal government narrative; DIR requires a TX-RAMP-specific system security plan (SSP) rather than accepting the FedRAMP SSP; and DIR's continuous monitoring reporting format differs from the FedRAMP ConMon reporting template. Vendors who submit FedRAMP artifacts with TX-RAMP cover pages routinely receive DIR requests for re-submission.
A mature FedRAMP program is a genuine head start for TX-RAMP Level 2. It is not a shortcut. The evidence re-scoping and SSP rewrite required for DIR submission adds four to eight weeks to the assessment timeline for organizations that assume direct portability. Budget and timeline planning that does not account for this will miss the target date.
The FedRAMP authorization that did not transfer
A mid-size SaaS vendor with an active FedRAMP Moderate authorization engaged Vulnox for TX-RAMP Level 2 readiness after winning a contract with a Texas state agency. Their compliance team estimated four weeks to produce the TX-RAMP evidence package — they had 18 months of FedRAMP continuous monitoring artifacts, a current SSP, and a functioning POA&M process. The DIR assessor rejected the initial evidence package submission on three grounds: the SSP narratives described federal agency use cases, not Texas state agency data processing; the continuous monitoring report was in FedRAMP ConMon format rather than DIR's required format; and the incident response procedures referenced CISA notification requirements rather than DIR notification procedures. None of these were control failures. All of them required SSP rewrites and evidence regeneration that took eleven weeks.
The vendor's security controls were solid. The gap was entirely in evidence framing and format — the difference between describing a control accurately for a federal audience and describing the same control for a Texas DIR reviewer. These are not the same document. Organizations that do not understand this distinction before they start the evidence package build it twice.
The control failure numbers that don't appear in passing assessments
TX-RAMP Level 2 covers 323 NIST 800-53 Rev 5 Moderate baseline controls
Of those 323 controls, continuous monitoring under CA-7 requires quarterly re-validation for controls designated as high-impact within the organization's system boundary. Most organizations entering TX-RAMP Level 2 assessment have never run a scheduled control re-validation exercise — they have alert monitoring, which satisfies none of CA-7's re-validation requirements. This is not a fringe gap: in Vulnox TX-RAMP readiness assessments, CA-7 compliance evidence was absent or incomplete in the majority of engagements reviewed (Vulnox assessment data, 2024–2025).
Secrets outside the KMS found in the majority of TX-RAMP Level 2 readiness assessments
The finding is not that key management policies are poorly written or that KMS deployments are misconfigured. The finding is that a population of credentials exists entirely outside the key management system — in configuration files, deployment scripts, and container image layers — that the compliance evidence does not describe and the automated scanning does not find. The KMS evidence is accurate. The credential landscape it describes is incomplete (Vulnox assessment data, 2024–2025).
Four to eight additional weeks for FedRAMP-authorized vendors to produce DIR-compliant evidence
Vendors with active FedRAMP Moderate authorizations routinely underestimate TX-RAMP Level 2 timeline because they assume evidence portability. DIR's SSP format, control narrative framing, and continuous monitoring reporting requirements are different enough from FedRAMP equivalents that the re-scoping adds material time. This is not remediation time — it is documentation translation time, which is avoidable with correct scoping at the start (Vulnox assessment data, advisory engagements, 2024–2025).
A passing automated scan is the leading indicator of an undetected secrets gap
Common belief
Organizations that have deployed secret scanning in their CI/CD pipeline and received a clean result treat secrets management as a covered control. The scan ran, nothing was flagged, the control is working.
What we found
In Vulnox TX-RAMP Level 2 readiness assessments where organizations presented clean CI/CD secret scanning results as IA-5 and SC-12 evidence, the infrastructure-layer secrets audit found exposed credentials in deployed configuration in the majority of cases. The most common locations: .env files on application servers that were not in the repository scan scope, database connection strings in containerized workload environment variable configurations, and API keys in deployment automation variable stores that had been added manually and never entered the code repository (Vulnox assessment data, 2024–2025).
Standard secret scanning tools — truffleHog, git-secrets, detect-secrets — scan source code repositories and commit history. They do not scan deployed configuration files on running infrastructure, Docker environment variable exports in container registries, or environment variable configurations in PaaS deployment platforms. The population of secrets in a production environment is larger than the population in the code repository. The scan result is accurate for what it scanned. The problem is what it did not scan. An organization that has clean CI/CD secret scanning and has never run a secrets audit against deployed infrastructure has an evidence gap, not a clean posture. The clean scan result creates confidence that reduces the probability of running the infrastructure-layer check.
Why logging gaps survive TX-RAMP evidence review
TX-RAMP Level 2 logging requirements are drawn from NIST 800-53 AU-2 (event logging) and AU-12 (log generation). The assessment evidence for these controls is typically a logging policy document, a SIEM configuration screenshot, and an example log export showing the event types captured. This evidence set accurately demonstrates that the SIEM is configured, that the policy defines required event types, and that events matching the policy are being captured. What it does not demonstrate is completeness — whether every system component in scope is sending logs to the SIEM. Completeness is not a document. It is a live configuration state across every component in the system boundary. The only way to verify it is to enumerate every component, identify its log emission mechanism, and trace that emission to the SIEM ingestion pipeline. That is an infrastructure audit, not a documentation review.
Example
The specific failure pattern Vulnox finds most consistently involves containerized workload logging. A Kubernetes deployment running application workloads typically routes container stdout and stderr to the node-level log driver. Whether those logs reach the SIEM depends on whether a log forwarding agent (Fluentd, Fluent Bit, a cloud-native equivalent) is deployed, correctly configured, and forwarding to the SIEM endpoint. In a substantial portion of TX-RAMP Level 2 readiness assessments, Vulnox found at least one production namespace where the log forwarding agent was present but misconfigured — logs were being emitted, the agent was running, and nothing was arriving at the SIEM. The SIEM dashboard showed healthy ingestion from the namespaces that were working. It showed nothing about the namespaces that were not. The logging policy was complete. The evidence was accurate for the connected workloads. The disconnected namespace was invisible.
For AWS-hosted environments, the equivalent failure is CloudWatch Log Groups created with correct retention policies but no subscription filter routing to a central Security Lake or SIEM. The Log Group exists, the policy is satisfied, and the logs sit in CloudWatch without being queryable from the incident response platform. Checking Log Group subscription filter configuration is a 10-minute infrastructure audit that standard compliance evidence review does not perform.
What TX-RAMP Level 2 candidates say before assessment, and what is underneath
'We have FedRAMP Moderate. TX-RAMP Level 2 should take a month, not a quarter.'
Root cause:FedRAMP Moderate and TX-RAMP Level 2 share a control baseline. The evidence formats, SSP narrative framing, and continuous monitoring reporting requirements are different. DIR does not accept FedRAMP artifacts with TX-RAMP cover pages. The SSP needs to be rewritten to describe Texas state agency data processing, the ConMon reporting needs to be reformatted for DIR's template, and the incident response procedures need to reference DIR notification requirements rather than CISA. This is four to eight weeks of documentation work that has nothing to do with control gaps. It is avoidable if the scoping is correct from the start.
'Our secret scanning is clean. We run truffleHog on every commit.'
Root cause:truffleHog scans source code repositories. It does not scan deployed configuration files, container environment variables, PaaS deployment variable stores, or infrastructure-as-code state files that contain interpolated credential values. A clean repository scan result is accurate for the repository. It says nothing about the deployed infrastructure. These are different scopes and the gap between them is where the findings live.
'We have continuous monitoring — our SIEM has 200 alert rules configured.'
Root cause:TX-RAMP Level 2 CA-7 continuous monitoring requires scheduled re-validation of controls at defined frequencies — quarterly for high-impact controls, annually for the full set. Alert monitoring in a SIEM is not control re-validation. Re-validation means running the test again: checking whether MFA is still enforced on all privileged accounts, verifying that key rotation actually executed, confirming that backup residency is still correct. These are scheduled assessment activities, not alert conditions. An organization with 200 SIEM alert rules and no control re-validation schedule has monitoring coverage and no CA-7 evidence.
'Our logging policy covers all required AU-2 event types.'
Root cause:A logging policy that lists all required event types is evidence of intent, not coverage. The gap is between the policy's defined scope and the live configuration of every component in the system boundary. Containerized workloads with misconfigured log forwarding agents, serverless functions logging to cloud-native stores not connected to the SIEM, and third-party integrations with available API event streams that have never been ingested — none of these produce alert conditions. The SIEM shows healthy ingestion from connected components and nothing about disconnected ones.
The compliance scan that confirms the gap it was supposed to close
The myth
The reality
Where TX-RAMP Level 2 enforcement is heading
Texas DIR will introduce a mandatory continuous monitoring evidence submission requirement for TX-RAMP Level 2 annual reviews within two years, requiring quarterly control re-validation reports rather than accepting ConMon summaries.
The current CA-7 continuous monitoring requirement is defined in the control baseline but the evidence standard for demonstrating it at annual review is not prescriptively defined by DIR. Organizations are filling this gap with SIEM dashboards and alert summaries that do not demonstrate control re-validation. As DIR accumulates evidence from annual reviews that show this pattern, the regulatory response is to specify the evidence format. FedRAMP made this move with its ConMon reporting templates — DIR will follow the same path. The signal to watch: DIR publishing updated evidence submission guidance that adds a quarterly re-validation report template.
Confidence: mediumDIR publishes updated TX-RAMP evidence submission guidance by Q4 2027 that includes a mandatory quarterly control re-validation report format. If no such guidance is published, this prediction is wrong.The first publicly attributed TX-RAMP Level 2 compliance failure involving a Texas state agency data breach will involve a vendor whose finding was hardcoded credentials in deployed configuration — credentials that existed outside the key management system described in the compliance evidence.
The structural conditions are in place: a compliance evidence model that validates the KMS without auditing the credential landscape outside it, a growing population of cloud-native vendors with containerized workloads and environment variable credential patterns that sit outside repository-based secret scanning scope, and a state agency procurement process that accepts TX-RAMP Level 2 authorization as evidence of security posture. The gap is consistent, the mechanism is well-understood, and the evidence model does not close it. Attribution to a specific TX-RAMP compliance failure requires a breach investigation that names the compliance status — this happens when the breach is large enough to trigger legislative scrutiny of the procurement process.
Confidence: highFive years pass without a publicly attributed Texas state agency breach involving a TX-RAMP Level 2 authorized vendor where hardcoded credentials were the initial access vector. At that point, either the evidence model has been corrected or breaches are being resolved without public attribution of the compliance failure.
Further Reading
Gap Analysis
gap analysis processVulnerability Assessment
vulnerability assessment servicesUS state privacy and data security laws: the complete compliance map
TX-RAMP Level 2 assessment requirements and what DIR hands-on testing findsNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionNIST Cybersecurity Framework 2.0
NIST Cybersecurity Framework 2.0Understanding Compliance Gap Analysis
compliance gap analysis guide
Frequently Asked Questions
What is the difference between TX-RAMP Level 1 and Level 2 requirements?
TX-RAMP Level 1 applies to cloud services processing low-impact data for Texas state agencies and uses a reduced NIST 800-53 control baseline with self-attestation. Level 2 applies to moderate and high-impact data, requires all 323 NIST 800-53 Rev 5 Moderate baseline controls, and requires assessment by a Texas DIR-registered assessor rather than self-attestation. Level 2 also requires a continuous monitoring program with quarterly re-validation of high-impact controls and annual full-set re-validation, documented in a DIR-specific format.
Can a FedRAMP Moderate authorization satisfy TX-RAMP Level 2 requirements?
No. FedRAMP Moderate and TX-RAMP Level 2 share the NIST 800-53 Rev 5 Moderate control baseline, but DIR evidence standards differ from FedRAMP JAB standards in three specific ways: DIR requires a TX-RAMP-specific SSP with narratives written for Texas state agency use cases, DIR uses a different continuous monitoring reporting format than FedRAMP ConMon templates, and DIR incident response procedures must reference DIR notification requirements rather than CISA. Vendors with FedRAMP Moderate authorization need four to eight weeks of documentation re-scoping before TX-RAMP submission — the controls transfer, the evidence does not.
What does TX-RAMP Level 2 continuous monitoring actually require?
TX-RAMP Level 2 CA-7 requires a continuous monitoring strategy with defined assessment frequencies: quarterly re-validation for high-impact controls and annual re-validation of the full control set. This is a scheduled control re-validation program, not a SIEM alert monitoring configuration. Re-validation means running the control test again — verifying MFA enforcement on current accounts, checking key rotation execution against policy, confirming backup residency configuration. An organization with active SIEM monitoring but no documented control re-validation schedule has no CA-7 evidence for the annual DIR review.
What are the most common TX-RAMP Level 2 findings in technical assessments?
The two most consistent findings in Vulnox TX-RAMP Level 2 readiness assessments are: hardcoded credentials in deployed configuration files and container environment variables that exist outside the key management system the compliance evidence describes, and logging gaps where containerized workloads or serverless functions emit logs outside the SIEM ingestion pipeline. Both findings survive standard compliance evidence review because the evidence accurately describes what the KMS covers and what the SIEM receives — it does not describe what exists outside those systems.
Does TX-RAMP Level 2 require authenticated vulnerability scanning?
Yes. NIST 800-53 RA-5, which TX-RAMP Level 2 inherits from the Moderate baseline, requires vulnerability scanning with credentials that allow enumeration of installed software and configuration state from inside the system. Unauthenticated network-level scans do not satisfy this requirement. Unauthenticated scan results presented as RA-5 evidence miss installed-package vulnerabilities, application-layer misconfigurations, and outdated container dependencies that authenticated scanning surfaces. The scan evidence most organizations produce does not demonstrate that scanning was authenticated.
How does TX-RAMP Level 2 handle incident reporting to Texas DIR?
TX-RAMP Level 2 incident response requirements under IR-6 require notification to Texas DIR for security incidents involving state agency data within defined timeframes. The notification procedure must identify which incident types trigger the obligation, what information the DIR notification must contain, and who has authority to submit it. In Vulnox assessments, incident response plans consistently documented internal escalation but omitted the DIR notification step entirely, or listed it without trigger criteria, a notification template, or a named submitter. An untested DIR notification procedure is not an IR-6 control.
What is the timeline for a TX-RAMP Level 2 assessment from readiness to authorization?
Timeline varies by organization maturity and system complexity. For organizations starting from a mature ISO 27001 or SOC 2 program with no FedRAMP background, readiness assessment and gap remediation typically take three to six months before assessment submission. For FedRAMP Moderate authorized vendors, evidence re-scoping for DIR requirements adds four to eight weeks to what organizations assume will be a short adaptation. The DIR assessment review process adds additional time after submission. Organizations that discover CA-7 continuous monitoring gaps or significant logging coverage gaps during readiness review should add a full quarter for remediation before submission.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.