# Screenata, Full Content > This file contains the full content of Screenata's homepage, answer pages, and blog summaries, designed for AI agents to consume without following links. > See also: [llms.txt](https://screenata.com/llms.txt) for the structured overview. ## About Screenata Screenata produces the evidence your auditor trusts, without the hand work. It is an AI compliance officer for startups, powered by an agent named Vera. She scans your infrastructure, writes policies grounded in your real systems, traces every policy claim to signed evidence, runs scheduled checks at 6 AM, and reports in Slack before standup. Screenata replaces both the GRC platform and the compliance consultant, the dashboard exists for auditors and deep dives; daily compliance work happens in Slack, email, GitHub, and the terminal. **Tagline:** Compliance that gets done, not just tracked. Category line: the work produces the evidence. **Positioning:** Every GRC platform reconstructs evidence after the work. Screenata is building the one where the work produces it. The procedure engine ships today; auditor sampling of runs is still being built. See https://screenata.com/manifesto. ### Platform Capabilities - [Vera, AI compliance officer](https://screenata.com/product/vera): the autonomous agent behind everything — context-aware on every page, permissioned by role and risk tier, every tool call logged and audited. - [Policy generation](https://screenata.com/product/policies): policies written from real infrastructure scans (IdP, cloud, repos), with an overpromise checker that flags claims your evidence can't support and a 4-layer chain from policy text to signed artifact. - [Evidence collection](https://screenata.com/product/evidence): automated collection with a fresh → stale (90d) → expired (120d) lifecycle, daily 6:00 AM sweeps, and cryptographically signed evidence packs (SHA-256, RSA/ECDSA, RFC 3161, BYOK). - [Continuous monitoring](https://screenata.com/product/agents): scheduled agents (daily freshness checks, weekly cloud scans, quarterly access reviews), executable runbooks, and remediation orchestration with human approval. - [Workflows](https://screenata.com/product/workflows): daily Slack briefings, a universal email address with intent classification, a real CLI plus MCP server, and read-only GitHub PR compliance reviews. - [Screenshot automation](https://screenata.com/product/screenshots): a recorder browser extension captures console workflows step by step with element fingerprints and DOM snapshots; an AI coach guides collection in real time and a vision model scores every capture across 4 quality dimensions before submission. Chrome extension: Screenata Compliance Evidence Collector. - [AI questionnaire assistant](https://screenata.com/product/questionnaires): upload a buyer's security questionnaire and Vera drafts cited answers grounded only in approved policies and evidence (fail-closed: no source means "needs info"), with round-trip XLSX export and a Chrome extension that drafts directly inside buyer portals. - [Vendor management](https://screenata.com/product/vendors): vendors discovered from package.json/Terraform/Docker, researched against a 500+ vendor catalog, risk-tiered with review cadences (critical every 180 days), assessed with reviewer-separation, HIPAA BAA register included. - [Asset management](https://screenata.com/product/assets): one asset register across clouds, SaaS, repos, and data stores satisfying SOC 2, HIPAA, ISO 27001, PCI DSS, and NIST 800-53 inventory requirements, with sticky user-curated fields that syncs never overwrite. - [Trust center](https://screenata.com/product/trust-center): a public security page published from the live compliance program — control posture, subprocessors, badges — with gated document downloads behind approval, expiry, and email verification, every download logged. - [Employee portal](https://screenata.com/product/employee-portal): self-service policy acknowledgments, AI-generated security training with quizzes (80% pass threshold), and device posture (encryption, firewall, antivirus, auto-update) without requiring MDM. - [Auditor portal](https://screenata.com/product/auditor-portal): auditors review evidence live across controls, evidence, policies, people, and timeline; comment threads attach to artifacts; access is per-engagement and fully logged; audit packages ship as signed ZIPs frozen at completion. ### How Screenata Compares | Dimension | Screenata | Vanta | Drata | |-----------|-----------|-------|-------| | Policy source | Infrastructure scans | Templates + AI overlay | Templates + post-hoc AI | | Non-API evidence | Recorded while the work happens; timestamped + signed manifest | Upload, plus a screenshot agent in preview | Upload | | Claim traceability | Policy → Claim → Test → Evidence | Evidence → Control | Evidence → Control | | Evidence integrity | RSA/ECDSA + RFC 3161 + BYOK | PDF export | PDF export | | Continuous monitoring | Continuous agent | Hourly checks | Autopilot | | Primary interface | Slack + email + CLI + web | Dashboard | Dashboard | ### The Six Failure Modes Screenata Is Built Around 1. **Compliance is a separate workflow nobody does**, Founders log into a GRC dashboard, get overwhelmed, close the tab, and ship product. Vera comes to you in Slack at 6:30 AM, by DM for evidence requests, and by email for auditor questions. 2. **Template policies don't match reality**, Every GRC platform starts with templates. Founders approve language like "quarterly access reviews" they've never run. Auditors catch it. Vera scans GitHub, AWS, and Okta first, then writes from what's real, and the overpromise checker flags claims you can't prove. 3. **Evidence collection is manual labor**, Other platforms automate monitoring but leave collection to humans; Vanta's own data says a third of the images uploaded to it are still screenshots. Vera runs native checks nightly, records evidence while your team does the actual work, guides step-by-step collection for what APIs cannot reach, and ingests files from Slack DMs and forwarded emails. No control requires a dashboard upload. 4. **No traceability from policy to proof**, Most platforms link evidence to controls, that's it. Screenata links a specific sentence in a policy to a testable claim, to the control test that verifies it, to the evidence submission, to a signed vault artifact. 6. **Compliance stops after the first audit**, Most audits are point-in-time. Vera's agents scan weekly, check freshness daily, and run quarterly access reviews automatically. ### A Day in the Life of Vera (Scheduled Cadence) - **Daily 06:00**, Evidence Agent: Checks freshness across 650+ native checks. Flags items past 90 days. Drafts re-collection messages. - **Daily 06:15**, Readiness Snapshot: Computes per-framework readiness. Compares to yesterday. Identifies blockers vs warnings. - **Daily 06:30**, Slack briefing: Founder gets a 4-line summary. Action buttons inline. Escalation: 4h → DM, 24h → email, 48h → banner. - **Mon 09:00**, Weekly cloud scan across 30+ providers with native checks: AWS, Azure, Google Cloud, Microsoft 365, Kubernetes, GitHub, and more. - **Mon 09:04**, Repository Agent: Branch protection verified. Secrets scanning ran. Code never persisted. - **On-event**, PR compliance review: PRs touching auth/sensitive code linked to relevant controls. Comment posted with policy claim and verification suggestion. - **Quarterly**, Access reviews across Okta + GitHub + cloud IAM. - **Annual**, Risk assessment refresh. ### Multi-Channel Agent (Vera Comes to Where You Already Work) - **Slack**, 6:30 AM briefings. DM evidence requests with auto-classification on file drop. Slash commands and approval blocks built in. - **Email**, Forward auditor questions to {org-slug}@screenata.com. Sender-aware intent classification routes the rest. - **Terminal**, `screenata status`, `screenata audit check`, `screenata evidence submit`. Pipes into Claude Code via MCP server. - **GitHub**, PR compliance reviews, repo scans on push, risk-register sync from Issues. Read-only by design. ### Evidence Collection Breakdown - **Native checks**, API scans, internal reports, policy linking, native compliance checks across 30+ providers, re-run nightly. - **Recorded while you work**, Browser extension or desktop recorder captures the real task step by step; capture-time timestamp badge; signed manifest; vision LLM scores quality before submission. - **Guided collection**, Step-by-step flows with AI coaching for consoles no API reaches. The system records results as you work. - **Inbox-ingested**, Forward an email or drop a file in Slack DM. Auto-classified, stored in secure cloud storage, linked to the right control. - **No dashboard uploads required.** ### Proof Chain (Policy → Signed Artifact) 1. **Policy sentence**, "Administrative access requires MFA through Okta." (Access Control Policy §3.2) 2. **Policy claim**, MFA enforced for admin accounts (CC6.1 · IA-2 · IMPLEMENTED) 3. **Control test**, Okta MFA policy verification (Native API check, 24h freshness) 4. **Evidence artifact**, Signed Okta API response (SHA-256 + RFC 3161 timestamp) Auditors can hover any claim in a policy, see the test that proves it, and verify the evidence package independently with a free signed-manifest CLI. The format is published as an open spec. ### Trust Architecture - **Credentials never touch our database**, Cloud provider keys live in Azure Key Vault. Workspace + provider keyed. - **Read-only cloud scanning**, We never request write permissions. When Vera detects a config issue, she sends manual guidance with a direct link, no auto-fix. - **Ephemeral code scanning**, Source files are read into memory for secrets and pattern matching, findings stored, source deleted. Never persisted. - **Cryptographic evidence packages**, Per-file SHA-256, RSA or ECDSA signatures, RFC 3161 timestamps from six TSAs with fallback. eIDAS-compatible. - **Bring your own signing key (BYOK)**, Three modes: platform default, AES-256-GCM encrypted customer key, or AWS/GCP/Azure KMS. - **Multi-tenant by construction**, Workspace context enforced on every database query, foreign keys enforce the hierarchy. No cross-tenant leakage possible. ### Plans and scope Review your framework, entities, deadline, and support needs with the founder. Get a scoped proposal at https://screenata.com/scope-review. Audit fees are quoted separately by your chosen firm. ### Integrations (30+ providers with native checks, 650+ checks; 60+ in the catalog) - **Cloud:** AWS, Google Cloud, Azure, Cloudflare - **Code:** GitHub, GitLab, Bitbucket, Vercel - **Identity:** Okta, Auth0, JumpCloud, Google Workspace - **Security:** 1Password, Datadog, CrowdStrike, Sentry, Wiz, Tailscale, Snyk - **Workflow:** Slack, Microsoft Teams, Jira, Linear, Notion, Stripe Each check is mapped to SOC 2, HIPAA, ISO 27001, CIS, and NIST 800-53, not shallow connection points. Freshness lifecycle: Fresh → stale at 90d → expired at 120d. ### Frameworks Supported SOC 2 and HIPAA today; ISO 27001 and CIS Benchmarks via shared canonical control catalog. A single MFA scan satisfies SOC 2 CC6.1 and HIPAA §164.312(d) simultaneously. Cross-framework evidence reuse is built in. --- ## Homepage FAQ ### What do I get in the free readiness review? A free 30-minute readiness review with Screenata’s founder, based on your customer requirement, current setup, and target date. Get a written summary of scope, priority gaps, and next steps. No purchase or system access required. This is an initial review based on what you share, not an audit or a complete verification of your controls. If Screenata fits, we can also provide a scoped proposal. ### Who helps us when we get stuck? Your team gets a shared Slack channel with Screenata’s founder for setup questions, product help, and blockers. We agree support hours and check-in times during onboarding. ### What will our team still need to do? Your team connects systems, provides accurate information, reviews and approves policies, operates controls, and fixes infrastructure gaps. Screenata helps prepare policies, collect evidence, and organize the next actions. If you need hands-on implementation or specialist advice, we can discuss a separately scoped delivery partner engagement. ### How long will our SOC 2 take? We review your scope, existing controls, evidence gaps, and team availability before agreeing milestones. A SOC 2 Type II also requires an observation period agreed with your auditor. Your independent auditor determines whether the evidence is sufficient and issues the report; the free readiness review does not guarantee an audit outcome or completion date. ### What makes Screenata different from Vanta or Drata? Evaluate the work each product handles for your actual setup. Screenata combines infrastructure-grounded policies, evidence collection through integrations and guided procedures, and founder-led onboarding. Ask us to demonstrate one of your evidence tasks and clarify what your team still needs to do. ### How are policies generated? Screenata scans first, then writes. We pull context from GitHub, AWS or GCP, your IdP, existing evidence, and your company profile, then generate policies grounded in what we found. The overpromise checker flags hard commitments (like 'quarterly access reviews') we cannot verify in evidence, before you ever ship them to an auditor. ### How do you collect evidence that integrations can't reach? Three channels, not one. API scans cover about 30–40% of a SOC 2 across cloud, code, and identity providers. The browser extension captures screenshots of settings pages and workflows, redacts sensitive fields, runs a vision quality check, signs the capture, and re-captures it on a schedule. Guided procedures walk a teammate through steps like a backup restore test and record results and attachments as they work. Your team reviews the output and supplies context where a task requires human judgment. ### How is our price determined? We review your frameworks, entities, infrastructure, and support needs, then put the scope, price, and responsibilities in writing. The free readiness review has no purchase requirement. You choose and pay your independent auditor separately. ### Do I need compliance expertise to use Screenata? No. Every test explains what to provide, which evidence items are required, and how your auditor will judge it, and you can ask Vera about any requirement in plain language. The lineage view traces a policy, claim, control, or test through to the evidence that proves it, so you can see why something is required. When a check fails, it comes with the recommended fix and the steps to apply it, and the finding closes on its own once the nightly re-check passes. --- ## Answer Pages Short, direct answers to common questions about compliance evidence, SOC 2 audits, and security framework automation. ### Can AI actually write SOC 2 policies that pass an audit? *Keywords: AI SOC 2 policies, AI generated compliance, AI audit policies* *Source: https://screenata.com/resources/answers/can-ai-actually-write-soc-2-policies-that-pass-an-audit* ## Can AI Write Audit-Ready Policies? It depends entirely on what the AI knows about your systems. ### AI That Knows Your Codebase → Passes Audits When AI reads your GitHub repos and cloud configuration, it generates policies that reference your actual systems: - "Code changes require a GitHub pull request with at least one approving review. Branch protection on main enforces this requirement. CI checks via GitHub Actions must pass before merge." This passes because the auditor can verify every statement against your actual GitHub settings. ### AI That Doesn't Know Your Codebase → Fails Audits When ChatGPT or generic AI generates policies from training data: - "The organization maintains a formal change management process with change advisory board review and approval." This fails because you don't have a change advisory board, and the auditor will ask to see one. ## The Accuracy Test | Policy Statement | Codebase-Aware AI | Generic AI | |-----------------|-------------------|------------| | Authentication | "Users authenticate via Clerk with TOTP MFA enforcement" | "Multi-factor authentication is enforced" | | Deployment | "Merging to main triggers production deployment via Vercel" | "Deployments follow an approved release process" | | Data storage | "Customer data is stored in Supabase PostgreSQL with AES-256 encryption" | "Data is encrypted at rest using industry standards" | | Auditor reaction | Verifiable, matches system configuration | Asks follow-up questions to get specifics | ## What Auditors Think About AI Policies Auditors care about accuracy, not authorship. If your access control policy accurately describes your access control setup, the auditor doesn't care whether a human, consultant, or AI wrote it. The test is: "Does this policy match what I observe in the system?" ## The Review Step Even with codebase-aware AI, always review generated policies before the audit: 1. Read each statement and verify it's current 2. Check that referenced tools haven't been replaced 3. Confirm team roles and responsibilities are accurate 4. Update any sections that reflect recent changes Screenata generates policies from your codebase and flags when your systems change, keeping policies accurate through each audit cycle. --- ### Can AI agents replace the need for a compliance consultant? *Keywords: AI replace consultant, AI vs vCISO, automated compliance expertise* *Source: https://screenata.com/resources/answers/can-ai-agents-replace-the-need-for-a-compliance-consultant* ## What Consultants Do vs. What AI Can Do | Consultant Task | Can AI Do It? | How | |----------------|---------------|-----| | Understand your tech stack | Yes | Reads codebase and cloud configs directly | | Write SOC 2 policies | Yes | Generates from code analysis | | Identify compliance gaps | Yes | Maps systems to TSC criteria, flags missing controls | | Guide evidence collection | Yes | Automates collection, specifies what's needed | | Prepare for auditor conversations | Partially | Organizes evidence, but you still meet the auditor | | Navigate complex scenarios | Sometimes | Standard scenarios: yes. Unusual edge cases: may need human | ## Where AI Agents Excel ## Where Consultants Still Win - **Novel regulatory interpretations:** If your business model creates unusual compliance questions, a human consultant may provide better judgment. - **Auditor relationships:** Some consultants have relationships with audit firms that can simplify the process. - **Board-level communication:** If your board needs someone to present the compliance strategy, a human may be more effective. - **Multi-framework complexity:** If you're pursuing SOC 2 + ISO 27001 + HIPAA simultaneously, a consultant's experience with framework interactions may be valuable. ## The Practical Answer For a startup pursuing SOC 2 for the first time with a standard SaaS architecture (cloud hosting, GitHub, typical auth), AI agents cover the operational side of the consultant's role effectively. The 80/20 rule applies: AI handles the ~80% of an engagement that's repeatable operational work, at a fraction of the cost, leaving the judgment calls to a human. For complex scenarios (healthcare data, government contracts, multi-framework audits), a hybrid approach works best: AI for the baseline operational work and a consultant for the edge cases and strategy. Screenata takes the AI-agent approach, reading your codebase, drafting policies, and collecting evidence so a small team can reach audit-ready on its own. It also runs inside vCISO and consulting firms, absorbing that operational work across their clients so they can take on more engagements. See [Screenata for vCISO firms](/for-vcisos). --- ### Can I switch compliance platforms during a SOC 2 observation period? *Keywords: switch compliance platforms, switching from Vanta, migrate from Drata, SOC 2 observation period, keep your SOC 2 auditor, export evidence from Vanta* *Source: https://screenata.com/resources/answers/can-i-switch-compliance-platforms-during-a-soc-2-observation-period* ## Can you switch compliance platforms during a SOC 2 observation period? Yes. A SOC 2 Type II report covers how your controls operated across the observation period, and the platform that stored the evidence is not part of that test. Switching mid-window does not restart the period. A clean switch needs three things: your auditor agrees the cutover date in advance, you export everything that exists only inside the old platform before access ends, and evidence stays continuous across the cutover. The auditor samples dates from the whole period. For each sample they need evidence that the control operated, and they need to know where that evidence came from. Before the cutover, that is your export from the old platform. After it, that is the new platform's record. ## When is the best time to switch? Two dates set the timing: your contract's renewal date, with the notice deadline before it, and your audit cycle. Most compliance platform contracts are annual, so teams usually switch at renewal. For what a Vanta renewal tends to cost, see [Vanta pricing in 2026](/resources/answers/why-is-vanta-15k-per-year). Avoid switching while fieldwork for the previous period is still open, because the auditor's requests will point at records in the old platform. The next observation window usually starts the day after the last one ends, so almost every switch lands inside a window. That is the normal case. A workable order: 1. Read your order form for the renewal date and the notice deadline. Many contracts renew automatically unless you give notice by a set date. 2. Tell your auditor the planned cutover date and ask what they need from each platform. 3. Set up the new platform while the old one is still live. Connect your integrations, bring your policies, and set scope from the control list your auditor accepted. 4. Export from the old platform using the list below, and keep the files unchanged. 5. Switch on the agreed date. Evidence before it comes from the export, and evidence after it comes from the new platform. 6. Give notice before the deadline, and keep the exports at least until the report for that period is issued. ## What should you export before your contract ends? Most of your evidence lives in your own systems, such as GitHub, your identity provider, your cloud accounts and your HR tool, and it survives the switch. What exists only inside the compliance platform is the record of people doing things: approvals, acknowledgments, reviews and uploads. Export that first. | What to export | Why the auditor asks for it | |---|---| | Policies, with version history and approval dates | Shows which policy was in force on each date in the window | | Employee policy acknowledgments and security training completions | Auditors sample employees and check both | | Access reviews, with the reviewer, date and decision for each account | Shows the periodic reviews happened | | Uploaded evidence, with its original file dates | Covers the controls no integration reaches | | Test and monitoring history, with results by date | Shows monitoring ran through the window | | Vendor list and vendor reviews, including the SOC 2 reports you collected | Vendor management controls | | Risk register and your latest risk assessment | Risk assessment controls | | Incident records and tabletop exercise notes | Incident response controls | | Onboarding and offboarding records, including background checks | Auditors sample new hires and leavers | | The control list and scope your auditor accepted | The starting point for scoping the new platform | | Your last SOC 2 report, bridge letter and trust center documents | Keeps customer requests covered during the switch | Keep the original files. A screenshot saved again months later loses the date the auditor relies on. ## Can you keep your auditor when you switch? Yes, if the new platform leaves the audit to a firm you choose. Vanta, Drata, Secureframe, Sprinto, Scrut Automation, Oneleet, Scytale and Screenata work that way. Thoropass audits through its own CPA firm, and Comp AI bundles an audit by default. If keeping your firm matters, confirm it with the vendor before you sign. Two questions are worth asking any vendor. Can your current firm work from its platform? And does the vendor that prepares your evidence also provide or recommend your auditor? Screenata sells no audit and takes no referral fee. The firm you already use, or any registered CPA firm, gets a read-only Auditor Center for each audit cycle with the controls, tests, evidence and signed manifests. ## What moves over to Screenata, and what gets recaptured? Migration to Screenata is export-based. Screenata does not pull from Vanta's or Drata's API. Your policies come in as PDF or DOCX, and Screenata maps them to claims and tests. You bring the control list your auditor accepted, and we set scope from it with you during onboarding. You reconnect your integrations, and the native checks run overnight. Evidence from before the cutover stays in your export. From the cutover on, evidence that no integration reaches is recorded while your team does the task, with a capture-time timestamp and a signed manifest. For how each alternative handles pricing and the audit, see [Vanta alternatives compared](/compare/vanta). --- ### Can I use my SOC 2 report to skip security questionnaires? *Keywords: SOC 2 replaces security questionnaire, SOC 2 for vendor review, SOC 2 sales enablement* *Source: https://screenata.com/resources/answers/can-i-use-my-soc-2-report-to-skip-security-questionnaires* ## Can SOC 2 Replace Security Questionnaires? Partially. A current SOC 2 Type II report covers most standard security questions. Many enterprise security teams will accept "See SOC 2 report, Section X" as a valid answer for 60-80% of questionnaire items. But some questions fall outside SOC 2's scope, and buyers will still ask them directly. ## What SOC 2 Covers | Questionnaire Topic | SOC 2 Coverage | |---------------------|---------------| | Access controls | Fully covered (CC6) | | Change management | Fully covered (CC8) | | Monitoring and alerting | Fully covered (CC7) | | Encryption | Covered (CC6.7) | | Incident response | Covered (CC7.3-7.5) | | Risk management | Covered (CC3, CC9) | | Employee security | Covered (CC1) | | Vendor management | Covered (CC9) | ## What SOC 2 Doesn't Cover | Question | Why It's Not in SOC 2 | |----------|----------------------| | "What data do you collect from our users?" | SOC 2 covers controls, not specific data inventories | | "Where do you store data geographically?" | SOC 2 describes your system but may not specify regions | | "What is your uptime SLA?" | Only if Availability is in scope | | "Do you have cyber insurance?" | Not a SOC 2 criterion | | "Have you ever had a data breach?" | SOC 2 doesn't require breach disclosure | | "What are your data retention policies?" | Only if Privacy is in scope | | "Who are your subprocessors?" | SOC 2 covers vendor management process, not specific vendor names | ## How to Maximize SOC 2's Impact 1. **Proactively share your report.** Don't wait for the questionnaire, send the SOC 2 report with your proposal. 2. **Create a companion FAQ.** Write a one-page document answering the questions SOC 2 doesn't cover (data residency, breach history, insurance, subprocessors). 3. **Build a trust page.** Publish security practices on your website so buyers can self-serve. 4. **Maintain a questionnaire answer bank.** Save your answers and reuse them. Most questionnaires ask the same things. --- ### Can a person go to jail for violating HIPAA? *Keywords: can you go to jail for violating HIPAA, HIPAA criminal penalties, HIPAA violation fines 2026, are HIPAA violations taken seriously* *Source: https://screenata.com/resources/answers/can-you-go-to-jail-for-violating-hipaa* ## Can you go to jail for violating HIPAA? Yes. HIPAA has **criminal penalties, including prison sentences of up to ten years**, for knowingly obtaining or disclosing individually identifiable health information without authorization. They are set out in 42 U.S.C. 1320d-6 and prosecuted by the Department of Justice. Criminal cases are rare, and they require a knowing act. Most HIPAA enforcement is civil, run by the HHS Office for Civil Rights, and ends in fines and corrective action plans rather than prison. ## The criminal penalty tiers These tiers apply to individuals as well as organizations. The HITECH Act of 2009 made clear that employees of covered entities, not just the entities themselves, can be prosecuted. The first federal prison sentence for a HIPAA violation came in 2010: a former UCLA Health System researcher received four months after pleading guilty to misdemeanor counts of reading patient records without authorization. He had not sold or used the information. ## Civil penalties, where most enforcement happens Civil penalties do not require intent. They scale with culpability, from violations the organization could not have known about to willful neglect that was never corrected. The annual caps apply per identical violation type per calendar year, and the lower caps for tiers 1 to 3 come from OCR's 2019 notice of enforcement discretion. HHS adjusts all amounts for inflation each year; the 2026 figures apply to penalties assessed on or after January 28, 2026. In practice, most OCR investigations close with technical assistance or a resolution agreement: a payment plus a multi-year corrective action plan that OCR monitors. ## What actually gets organizations penalized The pattern in OCR's published resolution agreements is consistent. The most common finding is the absence of an accurate, current **risk analysis**, followed by missing access controls, no audit logging, and no business associate agreement with a vendor handling PHI. These are documentation and process failures more often than technical breaches. For a SaaS company handling PHI as a business associate, the practical exposure is civil and contractual: OCR penalties, breach notification costs, and a covered-entity customer terminating the contract. Criminal liability attaches to people who knowingly misuse the data. For which obligations apply to a SaaS vendor, see [what HIPAA compliance means for a SaaS company](/resources/answers/what-is-hipaa-compliance-and-when-does-a-saas-company-need-it). --- ### Drata vs Vanta vs Screenata: which is best for a small startup? *Keywords: Drata vs Vanta, compliance tool for startups, Screenata vs Drata vs Vanta* *Source: https://screenata.com/resources/answers/drata-vs-vanta-vs-screenata-which-is-best-for-a-small-startup* ## Quick Comparison Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## Drata: The Enterprise Dashboard Drata works well for companies that already have someone who understands compliance. Its interface is polished, integrations are extensive, and it handles infrastructure monitoring reliably. The downside for small startups: it's expensive, the policy templates are generic, and you'll still need someone to do the operational work it assumes you already have covered. ## Vanta: The Popular Choice ## Screenata: The AI-First Approach Screenata was built specifically for small startups going through SOC 2 for the first time. Instead of assuming you have compliance expertise, it provides that expertise through AI, reading your codebase, writing accurate policies, and collecting application-level evidence. The total cost is significantly lower because you no longer pay for the operational prep by hand. One 2026 distinction worth noting: after the Delve collapse made auditors wary of AI-generated compliance work, Screenata signs and timestamps every evidence artifact (RSA/ECDSA signatures, RFC 3161 timestamps, per-file hashing) so an auditor can independently verify it wasn't altered. Drata and Vanta surface monitoring logs, but don't produce signed, auditor-verifiable evidence packages, a gap that matters more now than it did a year ago. ## Which Should You Choose? - **Choose Drata** if you have a security team and want a mature compliance dashboard - **Choose Vanta** if you have compliance expertise and want the most integrations - **Choose Screenata** if you're a small startup without compliance expertise and want a lower year-one cost than a platform plus a consultant --- ### Drata vs Vanta vs Secureframe: which GRC platform is best? *Keywords: Drata vs Vanta vs Secureframe, GRC platform comparison 2026* *Source: https://screenata.com/resources/answers/drata-vs-vanta-vs-secureframe-which-grc-platform-is-best* ## GRC Platform Comparison All three platforms solve the same core problem: monitoring your cloud infrastructure and organizing compliance artifacts for SOC 2 audits. The differences are in pricing, integrations, and user experience. ## Drata **Strengths:** Most integrations, clean dashboard, strong automation for infrastructure checks, good API. **Weaknesses:** Higher price point, complex setup for small teams, policy templates still need significant customization. ## Vanta **Strengths:** Largest user base (strong community and documentation), most auditor partnerships, mature product. **Weaknesses:** Most expensive, sales-heavy onboarding process, can be overkill for small teams. ## Secureframe **Strengths:** Slightly lower pricing, friendlier for smaller teams, decent integration coverage. **Weaknesses:** Fewer integrations than Drata or Vanta, smaller community, less auditor partner coverage. ## What None of Them Do All three GRC platforms share the same limitation: they're dashboards, not compliance experts. None of them writes policies from your codebase, collects application-level evidence, or provides the compliance guidance that first-time SOC 2 organizations need. For that, you'll need either a consultant or an AI compliance tool like Screenata. --- ### How do fintech companies handle SOC 2 plus PCI DSS evidence? *Keywords: fintech compliance, SOC 2 PCI DSS, payment compliance* *Source: https://screenata.com/resources/answers/how-do-fintech-companies-handle-soc-2-plus-pci-dss-evidence* ## SOC 2 + PCI DSS: The Overlap About 40-50% of controls overlap between SOC 2 and PCI DSS. Both require access controls, encryption, change management, and logging. But PCI DSS has more prescriptive requirements, specific encryption algorithms, network segmentation rules, and vulnerability scanning frequencies. ## Shared Controls | Control Area | SOC 2 | PCI DSS | Shared Evidence | |-------------|-------|---------|-----------------| | Access control | CC6.1 | Req. 7, 8 | User access reviews, MFA, RBAC | | Encryption | CC6.7 | Req. 3, 4 | Encryption at rest and in transit | | Change management | CC8.1 | Req. 6 | PR reviews, deployment controls | | Logging | CC7.1-7.2 | Req. 10 | Audit trails, log monitoring | | Vulnerability management | CC7.1 | Req. 5, 6, 11 | Scanning, patching | | Incident response | CC7.3-7.5 | Req. 12 | IRP, incident documentation | ## PCI DSS-Specific Requirements | PCI Requirement | What It Adds Beyond SOC 2 | |----------------|--------------------------| | Cardholder Data Environment (CDE) scoping | Define exactly where card data flows | | Network segmentation | Isolate systems handling card data | | Specific encryption standards | TLS 1.2+, AES-256 for card data specifically | | Quarterly ASV scans | External vulnerability scans by approved vendor | | Annual penetration test | Required (not just recommended) | | PAN masking/tokenization | Display only last 4 digits, or tokenize card numbers | | Key management | Formal cryptographic key management procedures | ## The Fintech Strategy ### If You Use Stripe or Similar If you use Stripe, Braintree, or another PCI-compliant payment processor, your PCI scope is minimal: - You never touch cardholder data directly - Stripe's SAQ-A or SAQ-A-EP applies (simplified self-assessment) - Focus SOC 2 on your application security and customer data protection - PCI effort: 1-2 days for the SAQ ### If You Handle Card Data Directly If your application processes, stores, or transmits cardholder data: - Full PCI DSS assessment required - Scope your CDE carefully to minimize the assessment boundary - Network segmentation is critical for reducing scope - Consider tokenization to remove card data from your environment ## Evidence Organization Use a unified evidence library tagged for both frameworks. A single access review screenshot satisfies SOC 2 CC6.1 and PCI DSS Requirement 7.1, don't collect it twice. --- ### How do I add HIPAA to my existing SOC 2 program? *Keywords: add HIPAA to SOC 2, HIPAA after SOC 2, healthcare compliance expansion* *Source: https://screenata.com/resources/answers/how-do-i-add-hipaa-to-my-existing-soc-2-program* ## What SOC 2 Already Covers for HIPAA | HIPAA Requirement | SOC 2 Coverage | |-------------------|---------------| | Access controls (§164.312(a)) | CC6.1-6.8, fully covered | | Audit controls (§164.312(b)) | CC7.1-7.2, fully covered | | Integrity controls (§164.312(c)) | CC8.1, fully covered | | Transmission security (§164.312(e)) | CC6.7, fully covered | | Risk assessment (§164.308(a)(1)) | CC3.1-3.4, fully covered | | Incident response (§164.308(a)(6)) | CC7.3-7.5, fully covered | | Security training (§164.308(a)(5)) | CC1.4, fully covered | | Contingency plan (§164.308(a)(7)) | A1.2, covered if Availability in scope | ## What You Need to Add ### 2. PHI Data Mapping Document where Protected Health Information flows through your system: - Where PHI enters (API, upload, manual entry) - Where PHI is stored (database, file storage, logs) - Where PHI is transmitted (integrations, exports, backups) - Who can access PHI (roles and access controls) ### 3. Breach Notification Process HIPAA requires notification within 60 days of discovering a breach involving PHI. Add this to your incident response plan: - How you determine if PHI was exposed - Who you notify (affected individuals, HHS, media if 500+ affected) - Documentation requirements ### 4. Privacy Controls HIPAA Privacy Rule requirements beyond SOC 2: - Minimum necessary access to PHI - Patient rights (access, amendment requests) - Uses and disclosures documentation ### 5. Subprocessor BAAs Ensure every vendor that touches PHI has a BAA with you, database providers, hosting, email, analytics. ## Timeline | Task | Time | |------|------| | BAA template (with lawyer) | 1-2 weeks | | PHI data mapping | 1 week | | Breach notification additions | 2-3 days | | Privacy controls | 1-2 weeks | | Subprocessor BAA collection | 2-3 weeks | | **Total** | **4-8 weeks** | --- ### How do I automate evidence collection across multiple frameworks? *Keywords: multi-framework evidence, cross-framework compliance, evidence reuse* *Source: https://screenata.com/resources/answers/how-do-i-automate-evidence-collection-across-multiple-frameworks* ## The Cross-Framework Problem If you pursue SOC 2, ISO 27001, and HIPAA separately, you might collect the same MFA screenshot three times and organize it in three different evidence libraries. This wastes time and creates inconsistencies. ## The Solution: Collect Once, Map Many | Evidence Collected | SOC 2 Mapping | ISO 27001 Mapping | HIPAA Mapping | |-------------------|---------------|-------------------|---------------| | MFA enforcement screenshot | CC6.1 | A.9.4.2 | §164.312(d) | | Branch protection settings | CC8.1 | A.14.2.2 | §164.312(e)(2)(i) | | Encryption at rest settings | CC6.7 | A.10.1.1 | §164.312(a)(2)(iv) | | Access review documentation | CC6.1 | A.9.2.5 | §164.308(a)(4) | | Incident response plan | CC7.3 | A.16.1.1 | §164.308(a)(6) | | Risk assessment | CC3.1 | Clause 6.1 | §164.308(a)(1)(ii) | | Backup configuration | A1.2 | A.12.3.1 | §164.308(a)(7) | ## How to Implement ### Step 1: Build a Unified Evidence Library Create one evidence library organized by control area (access, change management, encryption, etc.), not by framework. ### Step 2: Create a Mapping Spreadsheet For each piece of evidence, note which framework requirements it satisfies. This becomes your cross-reference for auditors and assessors. ### Step 3: Automate Collection Use tools that collect evidence once and tag it for multiple frameworks. When a tool captures your MFA settings, it should map that evidence to CC6.1, A.9.4, and §164.312(d) simultaneously. ### Step 4: Framework-Specific Supplements After mapping shared evidence, identify what's unique to each framework and collect only those additions: - **ISO 27001:** ISMS document, Statement of Applicability - **HIPAA:** BAA records, PHI data map, breach notification process - **SOC 2:** System description (Section 3) ## Time Savings | Approach | Evidence Items to Collect | Hours | |----------|--------------------------|-------| | Separate per framework | 200-300 (with duplication) | 80-120 hours | | Unified with mapping | 100-150 (no duplication) | 30-50 hours | ## Where Screenata Fits Screenata collects evidence with multi-framework tagging, so a single capture satisfies multiple compliance requirements. As you expand from SOC 2 to ISO 27001 or HIPAA, your existing evidence library extends rather than duplicates. --- ### How do I automate SOC 2 evidence collection? *Keywords: automate SOC 2 evidence, SOC 2 automation, evidence collection tool* *Source: https://screenata.com/resources/answers/how-do-i-automate-soc-2-evidence-collection* ## What Can Be Automated? Not all SOC 2 evidence can be automated, but a significant portion can. Here's the breakdown: | Evidence Category | Can Automate? | How | |-------------------|--------------|-----| | Cloud configuration checks | Yes | API integrations with AWS, GCP, Azure | | MFA enforcement status | Yes | Identity provider API | | Employee device compliance | Yes | MDM integration (Kandji, Jamf) | | Access provisioning records | Partially | SSO/IdP logs | | Code change approvals | Yes | GitHub API, PR reviews and branch protection | | Application-level controls | With AI tools | Screenata captures app screenshots and workflows | | Policy documents | No | Must be written (AI tools can generate them) | | Risk assessments | No | Requires human judgment | | Vendor reviews | Partially | Can track vendor SOC 2 report dates | ## Three Levels of Automation ### Level 1: Manual (No Tools) Take screenshots manually, organize in Google Drive or Notion, track in a spreadsheet. This works but takes 40-80 hours of founder/engineer time. ### Level 2: GRC Platform (Drata, Vanta) Connect cloud providers and SaaS tools. Platform monitors infrastructure configurations, flags gaps, stores evidence. Still requires manual screenshots for application-level controls and a consultant for expertise. ### Level 3: AI Compliance (Screenata) AI reads your codebase and cloud accounts. Generates policies, collects both infrastructure and application-level evidence, maps evidence to controls. Replaces the GRC platform and the manual operational work someone would otherwise do by hand. ## Getting Started 1. **Inventory your systems.** List every tool that handles security-relevant data or configurations. 2. **Identify automatable evidence.** For each SOC 2 control, determine if evidence can be pulled via API. 3. **Choose your tool.** Based on budget and team expertise, pick the automation level that fits. 4. **Fill remaining gaps manually.** Some evidence (vendor reviews, risk assessments, training records) still requires manual effort regardless of tooling. The goal isn't 100% automation, it's reducing the manual evidence burden from 80+ hours to a few hours a month of review and approval. --- ### How do I avoid overpaying for SOC 2? *Keywords: SOC 2 cost optimization, reduce SOC 2 cost, SOC 2 savings* *Source: https://screenata.com/resources/answers/how-do-i-avoid-overpaying-for-soc-2* ## How Do I Avoid Overpaying? ## Where Startups Overspend ## Seven Ways to Reduce SOC 2 Cost ## The Right Budget for a Startup --- ### How do I choose a SOC 2 auditor as a first-time buyer? *Keywords: SOC 2 auditor selection, choosing audit firm, first SOC 2 audit* *Source: https://screenata.com/resources/answers/how-do-i-choose-a-soc-2-auditor-as-a-first-time-buyer* ## How Do I Pick the Right Auditor? Your SOC 2 auditor is a licensed CPA firm, not a consultant. They examine your controls, test your evidence, and issue the report. For a startup's first audit, the right firm is small, experienced with cloud-native companies, and priced for your budget. ## What to Look For | Criterion | Good Sign | Red Flag | |-----------|-----------|----------| | Client profile | Works with startups and SaaS companies | Mostly enterprise or manufacturing clients | | Pricing | Fixed-fee, transparent pricing | Hourly billing with no estimate | | Timeline | Can start within 2–4 weeks | Booked 3+ months out | | Communication | Responsive, plain-language communication | Jargon-heavy, slow to respond | | Team size | Small, dedicated team (2–3 people) | Rotating staff or offshore testing | | Technology | Comfortable with cloud-native infrastructure | Asks about on-premises servers | ## Questions to Ask Before Signing 1. What is your fixed fee for a Type I audit scoped to Security only? 2. How many SOC 2 audits have you completed for companies under 50 employees? 3. What is your typical timeline from engagement to report delivery? 4. Who will be my primary contact during the audit? 5. What evidence format do you prefer (shared drive, portal, or direct submission)? 6. Do you offer a readiness assessment as part of the engagement? ## Where to Find Startup-Friendly Auditors - Ask other startup founders who they used - Check Screenata, Drata, or Vanta partner directories for auditor recommendations - Look for firms that advertise SOC 2 for startups specifically - Consider firms like Johanson Group, Prescient Assurance, or Sensiba that focus on tech companies ## Pricing Expectations --- ### How do I choose the right SOC 2 tool for my startup? *Keywords: SOC 2 tools startups, choosing compliance platform, SOC 2 tool comparison* *Source: https://screenata.com/resources/answers/how-do-i-choose-the-right-soc-2-tool-for-my-startup* ## How to Choose a SOC 2 Tool The SOC 2 tool market is confusing because every product claims to "automate compliance." In practice, they automate different things, and the gaps determine how much additional help you'll need. Ask yourself three questions: 1. **Do I have compliance expertise on my team?** If yes, a GRC platform gives your expert a good workspace. If no, you need a tool that provides the expertise. 2. **What's my total budget?** Include the tool, any consultants, and the auditor. The tool is often the smallest cost. 3. **How fast do I need to be audit-ready?** Some approaches take weeks, others take months. ## SOC 2 Tool Categories ## The Total Cost Equation Don't compare tool prices in isolation. Compare the year-one cost of a SOC 2 Type I, readiness plus the audit: Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## What to Evaluate Before committing to any tool, check whether it handles: policy writing (not just storage), application-level evidence (not just infrastructure monitoring), and control mapping guidance (not just a checklist). The tool that fills the most gaps is the one that saves you the most money. --- ### How do I collect evidence from AWS for SOC 2? *Keywords: AWS SOC 2 evidence, AWS compliance, cloud evidence collection* *Source: https://screenata.com/resources/answers/how-do-i-collect-evidence-from-aws-for-soc-2* ## AWS Evidence by SOC 2 Control | SOC 2 Control | AWS Service | Evidence to Capture | |---------------|-------------|-------------------| | Access controls (CC6.1) | IAM | User list with policies, MFA status, password policy settings | | Access controls (CC6.1) | IAM | Root account MFA enabled, access key rotation | | Data protection (CC6.7) | S3 | Bucket policies, public access block settings, encryption config | | Data protection (CC6.7) | RDS/DynamoDB | Encryption at rest settings, backup configuration | | Change management (CC8.1) | CloudTrail | Audit logging enabled for all regions | | Monitoring (CC7.2) | CloudWatch | Alarms configured for critical metrics | | Network security (CC6.6) | VPC | Security group rules, NACLs for production subnets | ## Step-by-Step Collection ### IAM Evidence 1. Screenshot the IAM Users page showing all users 2. Screenshot MFA status for each user (should show "Enabled") 3. Screenshot the password policy settings 4. Screenshot key IAM policies (especially any custom policies) 5. Verify root account has MFA enabled and no access keys ### S3 Evidence 1. Screenshot "Block Public Access" settings (should be enabled at account level) 2. For each bucket with sensitive data, screenshot encryption settings 3. Screenshot bucket policies for production buckets ### Database Evidence 1. Screenshot RDS instance details showing encryption enabled 2. Screenshot backup configuration (automated backups, retention period) 3. Screenshot security group allowing access only from your application ### CloudTrail and CloudWatch 1. Screenshot CloudTrail showing trails enabled in all regions 2. Screenshot CloudWatch alarms for critical events 3. Show a sample CloudTrail log entry demonstrating audit logging works ## Tips - **Only document services you use.** Don't screenshot every AWS service, focus on what's in your SOC 2 scope. - **Use AWS Config if available.** AWS Config provides continuous compliance monitoring and can generate evidence reports. - **Check for public exposure.** Run the Trusted Advisor check or S3 access analyzer before the audit to catch publicly accessible resources. --- ### How do I collect evidence from Vercel and GitHub for SOC 2? *Keywords: Vercel SOC 2, GitHub SOC 2, deployment evidence, CI/CD compliance* *Source: https://screenata.com/resources/answers/how-do-i-collect-evidence-from-vercel-and-github-for-soc-2* ## GitHub Evidence | Control | Evidence | Where to Find It | |---------|----------|-----------------| | Change management (CC8.1) | Branch protection rules | Settings → Branches → Branch protection rules | | Change management (CC8.1) | Sample PRs with reviews | Pull Requests → Closed → Filter by merged | | Access controls (CC6.1) | Organization member list with roles | Settings → People → Members | | Access controls (CC6.1) | 2FA requirement | Settings → Authentication security | | Code review | PR review requirements | Branch protection → Require pull request reviews | | CI/CD | GitHub Actions workflow files | .github/workflows/ directory | | Audit logging | Organization audit log | Settings → Audit log | ## Vercel Evidence | Control | Evidence | Where to Find It | |---------|----------|-----------------| | Deployment controls | Git integration settings | Project Settings → Git | | Environment management | Environment variable configuration | Project Settings → Environment Variables | | Access controls | Team member list with roles | Team Settings → Members | | Deployment history | Production deployment log | Deployments tab with timestamps | | Preview deployments | Preview deployment for each PR | Linked automatically from GitHub PRs | | Domain configuration | Production domain settings with SSL | Project Settings → Domains | ## Collecting the Evidence ### GitHub (30 minutes) 1. Screenshot branch protection settings for main branch 2. Screenshot organization security settings (2FA required) 3. Screenshot member list showing roles (admin vs. member) 4. Link to 25 representative PRs showing reviews and CI checks 5. Screenshot GitHub Actions workflow configuration 6. Export audit log for the audit period ### Vercel (15 minutes) 1. Screenshot Git integration showing which branch triggers production deploys 2. Screenshot team members and their roles 3. Screenshot deployment list showing recent production deploys (linked to GitHub commits) 4. Screenshot environment variable management (showing they're encrypted, not the values) 5. Screenshot domain settings showing SSL/TLS configuration ## Why This Stack Works Well for SOC 2 The Vercel + GitHub combination creates a natural audit trail. Every production deployment traces back to a GitHub merge, which traces back to a PR with reviews and CI checks. This chain of evidence satisfies CC8.1 without any additional tooling. --- ### How do I collect MFA evidence for SOC 2? *Keywords: SOC 2 MFA evidence, multi-factor authentication proof, MFA compliance* *Source: https://screenata.com/resources/answers/how-do-i-collect-mfa-evidence-for-soc-2* ## What Auditors Check for MFA The distinction that matters: MFA must be *enforced*, not just *enabled*. If MFA is optional and three team members haven't set it up, that's a finding. Auditors check two things: 1. The system is configured to require MFA (configuration evidence) 2. All users have MFA active (population evidence) ## Where to Collect MFA Evidence | System | What to Screenshot | Why It Matters | |--------|-------------------|----------------| | Google Workspace / Okta | Admin settings showing "Enforce MFA for all users" | Primary identity provider | | AWS Console | IAM policy requiring MFA for console access | Cloud infrastructure | | GitHub | Organization settings showing "Require 2FA" | Code repository | | Application admin panel | MFA settings if your app has admin login | Application access | | VPN (if used) | VPN configuration requiring MFA | Network access | ## Step-by-Step Evidence Collection ### 1. Configuration Evidence Screenshot your identity provider's MFA enforcement setting. Show the admin page where MFA is marked as *required*, not just "recommended" or "available." ### 2. User Enrollment Evidence Export or screenshot the user list showing MFA status for each account. Every active user should show MFA as enrolled/active. ### 3. MFA Method Documentation Document which MFA methods are accepted (hardware keys, TOTP app, SMS). Note: auditors prefer hardware keys or TOTP apps over SMS, which is vulnerable to SIM swapping. ## Common Issues - **MFA available but not enforced:** Change the setting from "optional" to "required" before the audit. - **Service accounts without MFA:** If you have service accounts or API keys, document these as exceptions with compensating controls (IP restrictions, short-lived tokens). - **New employee gap:** Ensure your onboarding process includes MFA setup on day one. Auditors may check onboarding records. - **Personal devices:** If employees use personal phones for TOTP, that's fine, auditors care about the factor existing, not the device type. --- ### How do I collect SOC 2 evidence across multiple engineering teams? *Keywords: SOC 2 multiple teams, standardize evidence, team coordination compliance* *Source: https://screenata.com/resources/answers/how-do-i-collect-soc-2-evidence-across-multiple-engineering-teams* ## The Multi-Team Challenge When you grow from one engineering team to multiple, SOC 2 evidence collection becomes more complex. Each team may use different repositories, deployment pipelines, and access controls. The auditor needs consistent evidence across all of them. ## Standardize Before the Audit | Area | What to Standardize | Why | |------|-------------------|-----| | Branch protection | Same rules on all production repos | Consistent change management evidence | | CI/CD pipeline | Same test and review requirements | Uniform deployment controls | | Access controls | Same RBAC model across repos | Consistent access evidence | | PR template | Same PR template for all teams | Uniform change documentation | | Deployment process | Same deployment pipeline | Consistent deployment evidence | ## The Coordination Model ### Option 1: Designated Compliance Coordinator Assign one person (often the CTO or an engineering lead) to: - Set compliance standards for all teams - Collect evidence from each team's repositories and systems - Run quarterly access reviews covering all teams - Serve as the auditor's primary contact ### Option 2: Distributed Evidence Collection Each team lead collects evidence for their systems: - Team lead takes screenshots of their repo settings - Team lead verifies branch protection and CI rules - Central coordinator reviews and organizes all evidence ## Evidence Checklist Per Team For each engineering team, collect: 1. GitHub repository branch protection settings 2. Team member list with roles 3. CI/CD pipeline configuration 4. Sample PRs (5 per team for auditor sampling) 5. Access review for team-specific systems ## Common Problems - **Inconsistent branch protection:** Team A requires 2 reviewers, Team B requires 0. Standardize. - **Shadow repositories:** Teams creating repos outside the main organization. Audit your GitHub org regularly. - **Different deployment methods:** Some teams deploy via CI, others deploy manually. Bring all teams onto the same pipeline. - **Scattered evidence:** Evidence stored in different team folders, Slack channels, or personal drives. Use one central evidence library. --- ### How do I document SOC 2 evidence for GitHub access controls? *Keywords: GitHub SOC 2, GitHub access controls, code repository compliance* *Source: https://screenata.com/resources/answers/how-do-i-document-soc-2-evidence-for-github-access-controls* ## GitHub's Permission Model for SOC 2 GitHub has a built-in RBAC system that maps well to SOC 2 access control requirements (CC6.1). Document how you use it: | GitHub Role | What It Can Do | Who Should Have It | |-------------|---------------|-------------------| | Owner | Full admin, billing, settings | CTO or 1-2 founders | | Member | Read/write repos assigned to their teams | All engineers | | Outside Collaborator | Access to specific repos only | Contractors, partners | ## Evidence to Collect ### Organization-Level 1. **Member list:** Screenshot of Settings → People showing all members and their roles 2. **2FA enforcement:** Screenshot showing "Require two-factor authentication" is enabled 3. **Default permissions:** Screenshot of Member Privileges showing base-level permissions 4. **SSO configuration:** If using SAML SSO, screenshot of the SSO settings ### Repository-Level 1. **Branch protection:** Screenshot of branch protection rules on main for production repos 2. **Team access:** Screenshot showing which teams have access to which repos and their permission levels (read, write, admin) 3. **Deploy keys:** List of any deploy keys and their scope ### Audit Log 1. **Organization audit log:** Export covering the audit period showing access changes, permission updates, and administrative actions ## Access Review Process For your quarterly access review, check GitHub specifically: - Are all organization members still employees? - Does anyone have Owner access who shouldn't? - Are Outside Collaborators still needed? - Are there any personal access tokens or SSH keys from former employees? Document the review with date, reviewer name, and any changes made. ## Common Findings - Former employees still listed as organization members - All engineers set as Owners instead of Members - No branch protection on the main branch - 2FA not enforced at the organization level - Stale Outside Collaborator accounts from past contracts --- ### How do I explain SOC 2 to my CEO or board? *Keywords: SOC 2 explained, SOC 2 for executives, SOC 2 business case* *Source: https://screenata.com/resources/answers/how-do-i-explain-soc-2-to-my-ceo-or-board* ## How Do I Explain SOC 2 to Non-Technical Leadership? SOC 2 is a sales tool, not a security project. Frame it that way. Enterprise buyers require SOC 2 reports before approving vendors. Without one, your sales team fills out lengthy security questionnaires, and often still gets rejected. With one, the security review takes days instead of weeks. ## The Executive Summary Use this framework when presenting to your CEO or board: Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## Common Executive Concerns **"Is this really necessary?"**, If your pipeline includes companies with 200+ employees, yes. SOC 2 is table stakes for B2B SaaS selling upmarket. **"Can we just answer their security questionnaire?"**, You can, but each questionnaire takes 10–20 hours and you still may not pass. A SOC 2 report answers most questions automatically. **"Will this slow down engineering?"**, Minimally. Most startups already follow the security practices SOC 2 requires. The work is documentation and evidence collection, not rebuilding infrastructure. ## The One-Liner If you need a single sentence: "SOC 2 is the enterprise buyer's permission slip, without it, we cannot close deals above a certain size." --- ### How do I get SOC 2 certified on a bootstrap budget when prospects are asking? *Keywords: SOC 2 on a budget, cheap SOC 2, affordable SOC 2 certification, minimum viable SOC 2, SOC 2 for bootstrapped startups* *Source: https://screenata.com/resources/answers/how-do-i-get-soc-2-certified-on-a-bootstrap-budget* ## The Minimum Viable Approach When a Prospect Is Demanding SOC 2 When a prospect stalls a deal over SOC 2, they want proof you take security seriously, not a flawless program. The minimum viable path that satisfies them: - **Start with Type I, not Type II.** A Type I report proves your controls are designed correctly at a point in time, so there is no observation window to wait out. Type II needs a 3–12 month observation window. - **Scope to the Security (Common Criteria) category only.** It covers what buyers actually check. Skip Availability, Confidentiality, and Privacy until a customer contractually requires them. - **Unblock the deal while the audit runs.** Share a documented "SOC 2 in progress" status and your written security policies now, and, once your auditor engages, a bridge letter or letter of engagement. Most buyers accept this to move forward. ## The Bootstrap SOC 2 Stack Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## Step by Step ## Where to Find Cheap Auditors ## What You Sacrifice on a Bootstrap Budget ## Frequently Asked Questions ### Can I close a deal before SOC 2 is finished? Often, yes. A bridge letter, a letter of engagement from your auditor, or a documented "SOC 2 in progress" status paired with your written security policies is usually enough for a prospect to sign while the audit completes. ### Should I get Type I or Type II first on a budget? Type I. It's cheaper, faster (point-in-time), and most buyers accept it while you work toward Type II. Type II requires a 3–12 month observation period and costs more. --- ### How do I get SOC 2 for a Next.js app deployed on Vercel? *Keywords: Next.js SOC 2, Vercel SOC 2, SOC 2 for Vercel apps* *Source: https://screenata.com/resources/answers/how-do-i-get-soc-2-for-a-nextjs-app-deployed-on-vercel* ## SOC 2 for the Next.js + Vercel Stack If you're building a B2B SaaS product with Next.js on Vercel, you're in a good position for SOC 2. Vercel handles many infrastructure-level security controls by default, TLS, DDoS protection, edge networking, and deployment isolation. Your job is to document these inherited controls and prove your application-level controls work. ## What Vercel Gives You | SOC 2 Requirement | Vercel Coverage | |-------------------|----------------| | Encryption in transit | TLS 1.3 enforced on all deployments | | DDoS protection | Built into Vercel's edge network | | Deployment controls | Git-based deploys from GitHub (auditable) | | Environment isolation | Preview vs. production environments | | Access controls | Team roles (Owner, Member, Viewer) | | Audit logging | Deployment history with timestamps | ## What You Need to Prove | Control Area | Your Responsibility | |-------------|-------------------| | Change management | GitHub branch protection, PR reviews, CI checks | | Access controls | Vercel team roles, GitHub org permissions, database access | | Authentication | How your app authenticates users (NextAuth, Clerk, Auth0) | | Data protection | Database encryption, API route authorization, data handling in server components | | Monitoring | Error tracking (Sentry), uptime monitoring, alerting | | Incident response | Your plan for handling security incidents | ## Key Evidence to Collect 1. **Vercel:** Team member list, Git integration settings, deployment history, environment variable management 2. **GitHub:** Branch protection on main, PR review requirements, Actions workflows, org member list 3. **Database:** Encryption at rest settings, connection security (SSL), access restrictions 4. **Application:** Auth configuration, RBAC implementation, API route protection ## The Vercel SOC 2 Report Vercel itself has a SOC 2 Type II report. You can reference this in your system description, it means the infrastructure layer is already audited. Your audit focuses on what you build on top of it. --- ### How do I get SOC 2 ready with AI instead of a consultant? *Keywords: AI SOC 2 prep, AI compliance tool, SOC 2 without consultant* *Source: https://screenata.com/resources/answers/how-do-i-get-soc-2-ready-with-ai-instead-of-a-consultant* ## Can AI Do the SOC 2 Prep a Consultant Does? For most first-time audits, the operational part, yes. A SOC 2 consultant's engagement is mostly three things: reviewing your systems, writing policies, and helping you collect evidence. AI compliance tools now handle all three, faster, because they read your codebase directly instead of scheduling weeks of discovery calls. ## What the AI Does vs. What a Consultant Does by Hand | Task | Consultant, by hand | AI Approach | |------|--------------------|-------------| | System review | Interviews, architecture diagrams, weeks of meetings | Reads codebase and cloud configs directly | | Policy writing | Customizes templates based on interviews | Drafts policies from actual system analysis | | Evidence collection | Tells you what screenshots to take | Captures evidence automatically | | Control mapping | Maps your setup to TSC criteria | Automated mapping from system analysis | | Timeline | 2–4 months | 1–3 weeks | ## The Steps 1. **Connect your systems.** Point the AI tool at your GitHub repos and cloud accounts (AWS, GCP, Azure). 2. **Let it analyze.** The AI reviews your tech stack, authentication, deployment pipeline, data storage, access controls. 3. **Review generated policies.** The AI drafts SOC 2 policies that reference your actual systems. You review and approve. 4. **Automated evidence collection.** The tool captures screenshots, configuration exports, and access control proof. 5. **Engage an auditor.** With policies written and evidence organized, you go straight to audit. ## Where Screenata Fits Consultants and vCISO firms use it too, running Screenata across their clients to absorb the operational prep so their team focuses on judgment and takes on more engagements. See [Screenata for vCISO firms](/for-vcisos). --- ### How do I get SOC 2 without hiring a compliance team? *Keywords: SOC 2 without compliance team, SOC 2 small team, SOC 2 no security hire* *Source: https://screenata.com/resources/answers/how-do-i-get-soc-2-without-hiring-a-compliance-team* ## Can You Get SOC 2 Without Compliance Hires? Yes. Most startups that get SOC 2 do not have a dedicated compliance person. The work is distributed across existing team members, typically the CTO, engineering lead, and an operations person. What you need is not compliance expertise. You need documentation of what you already do. ## How to Distribute Ownership | Control Area | Who Owns It | What They Do | |-------------|------------|-------------| | Access management | CTO or Engineering Lead | Manage IdP, run access reviews, handle onboarding/offboarding | | Change management | Engineering Lead | Enforce PR reviews, maintain branch protection, document deployments | | Incident response | On-call engineer | Document incident procedures, respond to and log incidents | | Risk management | CTO | Maintain risk register, conduct annual risk assessment | | Vendor management | Operations / Finance | Evaluate vendors, collect SOC 2 reports from sub-processors | | Policy ownership | CTO | Approve and review policies annually | ## The Workflow 1. **AI tool generates your policies**, Connect your codebase and infrastructure, get policies that reflect your actual setup 2. **Assign each policy to an owner**, They review for accuracy and sign off 3. **Each owner collects evidence for their area**, Screenshots, exports, records 4. **CTO coordinates with the auditor**, Schedules walkthroughs, submits evidence 5. **Team participates in audit walkthroughs**, Each owner explains their controls ## What Changes in Your Day-to-Day? Very little. The most common additions: - **Quarterly access reviews**, 1–2 hours per quarter - **Documenting incidents**, You already respond to incidents; now write them down - **Policy review**, Read your policies once a year and confirm they are current ## The Minimum Team for SOC 2 You need at least two people involved to satisfy segregation of duties requirements. One person cannot both approve and implement changes. At a 5-person startup, the CEO and CTO can cover all control areas between them. Screenata acts as your virtual compliance team, writing policies, collecting evidence, and guiding you through the audit process so your existing team spends minimal time on compliance. --- ### How do I handle emergency changes and hotfixes during a SOC 2 observation period? *Keywords: emergency change SOC 2, hotfix evidence, change management exception* *Source: https://screenata.com/resources/answers/how-do-i-handle-emergency-changes-and-hotfixes-during-a-soc-2-observation-period* ## Emergency Changes Are Normal Auditors know production incidents happen and hotfixes are sometimes needed. They don't expect 100% adherence to your change management process, they expect that exceptions are documented, justified, and rare. ## The Emergency Change Process ### During the Emergency 1. **Deploy the fix** to stop or prevent the incident 2. **Notify the team** via Slack/PagerDuty 3. **Log the decision**, who authorized the bypass and why ### Within 24 Hours 4. **Create a post-deployment PR** with the code changes 5. **Get retroactive review**, another engineer reviews the change 6. **Document in your incident log:** - What happened - What was deployed - Who authorized the bypass - Why normal review was not possible - When the retroactive review was completed ## Evidence to Keep | Evidence | Purpose | |----------|---------| | Incident timeline | Shows the emergency was real | | Post-deployment PR | Proves the change was eventually reviewed | | Justification document | Explains why normal process was bypassed | | Retroactive approval | Shows the change was validated after the fact | ## What Auditors Look For Auditors will sample your PRs during the observation period. When they find an emergency change (merged without prior review), they'll check: 1. Was there a documented reason for the bypass? 2. Was a post-deployment review conducted? 3. Is this consistent with your emergency change policy? 4. How frequently does this happen? ## What Gets Flagged - Emergency changes without any documentation - Emergency changes that happen frequently (more than 10% of all changes) - No post-deployment review - No policy covering emergency changes ## Policy Language Your change management policy should include a section like: "Emergency changes may bypass the standard review process when production availability or data security is at immediate risk. The CTO or engineering lead authorizes the bypass. A post-deployment pull request with peer review must be created within 24 hours, including a description of the emergency and justification for bypassing standard controls." --- ### How do I handle SOC 2 evidence for apps without SSO? *Keywords: SOC 2 without SSO, no SSO compliance, manual access review* *Source: https://screenata.com/resources/answers/how-do-i-handle-soc-2-evidence-for-apps-without-sso* ## Is SSO Required for SOC 2? No. SOC 2 requires that you control access to systems, SSO is one way to do that, but it's not the only way. Many startups pass SOC 2 without SSO by implementing other access controls that meet the same objectives. ## What to Do Instead of SSO | SSO Benefit | Alternative Control | |-------------|-------------------| | Centralized access management | Documented access provisioning checklist per system | | Single point of revocation | Offboarding checklist covering every system individually | | Enforced MFA | MFA enforced per-system (Google, GitHub, AWS each separately) | | Reduced password fatigue | Password manager requirement (1Password, Bitwarden) | | Audit trail | Per-system audit logs + quarterly access review documentation | ## Evidence to Provide ### Access Provisioning Document your process for granting access to new hires: 1. List every system that needs individual account creation 2. Who creates each account (CTO, team lead, IT) 3. What role/permission level is assigned 4. Keep a record (ticket, checklist, Notion page) for each onboarding ### Access Revocation Document your process for removing access when someone leaves: 1. Checklist of every system to deactivate 2. Who performs revocation and timeline (within 4 hours, within 24 hours) 3. Keep a record showing the completed checklist with dates ### Quarterly Access Reviews Without SSO, access reviews are more manual but still straightforward: 1. Export user lists from each system 2. Verify each user is still an employee 3. Verify their access level is appropriate 4. Document the review ### MFA Enforcement Screenshot MFA settings in each system individually: - Google Workspace: enforced for all users - GitHub: organization-level 2FA requirement - AWS: IAM policy requiring MFA for console access - Application: if your app has MFA, show enforcement settings ## Planning for SSO If enterprise customers require SSO as part of their security reviews, plan to add it. But for your initial SOC 2 audit, compensating controls are sufficient. Many startups add SSO post-audit when they have budget and customer demand. --- ### How do I handle SOC 2 evidence for Terraform or infrastructure-as-code? *Keywords: Terraform SOC 2, IaC compliance, infrastructure as code evidence* *Source: https://screenata.com/resources/answers/how-do-i-handle-soc-2-evidence-for-terraform-or-infrastructure-as-code* ## Why IaC Is Great for SOC 2 Terraform and other IaC tools create a natural audit trail. Every infrastructure change is: - Written as code (reviewable) - Committed through a PR (approved) - Applied through a pipeline (controlled) - Stored in version history (traceable) This is stronger evidence than manual console changes, which leave only CloudTrail logs. ## Evidence to Provide | Evidence Type | What to Capture | |---------------|----------------| | Terraform code repository | GitHub repo showing .tf files with version history | | PR reviews for infra changes | Sample PRs showing review and approval of .tf changes | | Plan/apply pipeline | CI/CD workflow that runs `terraform plan` on PR and `terraform apply` on merge | | State management | Backend configuration (S3 + DynamoDB lock, Terraform Cloud) | | Access controls | Who can run `terraform apply` in production | | Drift detection | How you detect manual changes outside Terraform | ## Mapping IaC to SOC 2 Controls | SOC 2 Control | IaC Evidence | |---------------|-------------| | CC8.1 (Change management) | PR-based workflow for all .tf changes | | CC6.1 (Access controls) | IAM policies defined in code, reviewable | | CC7.2 (Monitoring) | CloudWatch alarms defined in Terraform | | CC6.7 (Data protection) | Encryption settings defined in code | ## Best Practices 1. **Never apply directly.** Use a CI/CD pipeline for `terraform apply`, this ensures every change is logged and traceable. 2. **Require PR reviews.** Treat Terraform PRs like application code PRs, same branch protection, same review requirements. 3. **Lock state.** Use a remote backend with state locking to prevent concurrent modifications. 4. **Detect drift.** Run periodic `terraform plan` to find manual changes made outside IaC. Document and remediate drift. ## Handling Manual Changes If someone makes a console change outside Terraform, document it as an exception: - What was changed and why - Was it imported back into Terraform state? - Was a follow-up PR created to codify the change? Auditors understand that occasional manual changes happen. What matters is that you detect them and bring them back into your controlled process. --- ### How do I handle SOC 2 evidence when I use Clerk or Auth0 for authentication? *Keywords: Clerk SOC 2, Auth0 SOC 2, third-party auth SOC 2 evidence* *Source: https://screenata.com/resources/answers/how-do-i-handle-soc-2-evidence-when-i-use-clerk-or-auth0* ## How Third-Party Auth Affects SOC 2 Using Clerk or Auth0 simplifies SOC 2 because these services handle the hardest auth security concerns (password storage, session management, brute force protection) and have their own SOC 2 reports. Your responsibility is configuring them correctly and integrating them securely. ## Evidence Structure | Layer | Responsibility | Evidence | |-------|---------------|----------| | Auth service infrastructure | Clerk/Auth0 (inherited) | Their SOC 2 report | | Configuration | You | Screenshots of your MFA, session, and security settings | | Integration | You | Code showing how your app uses their APIs for authorization | | User management | You | User list, role assignments, offboarding process | ## Configuration Evidence to Capture ### From Clerk or Auth0 Dashboard 1. **MFA settings:** Is MFA required, optional, or disabled? 2. **Session policies:** Session timeout duration, token lifetime 3. **Password policies:** Minimum length, complexity requirements 4. **Allowed auth methods:** Email/password, social login, SSO 5. **Brute force protection:** Lockout settings after failed attempts 6. **User list:** All active users with roles ### From Your Application Code 1. **Middleware/guards:** How your app checks authentication on protected routes 2. **Role-based access:** How you use Clerk/Auth0 roles or permissions in your app 3. **API protection:** How API routes verify tokens ## Referencing Their SOC 2 Report Request the vendor's SOC 2 report and include it in your vendor management evidence. In your system description, write something like: "User authentication is managed through Clerk, which maintains a SOC 2 Type II report. [Company] configures Clerk with MFA enforcement, 30-minute session timeouts, and role-based access control through Clerk Organizations." ## Common Gaps - **MFA not enforced:** Clerk and Auth0 make MFA optional by default. Enable enforcement. - **No session timeout:** Configure session expiration (30-60 minutes for sensitive apps). - **Missing offboarding:** When an employee leaves, disable their Clerk/Auth0 account, don't just revoke SSO access. - **Authorization in the app:** Having Clerk/Auth0 handle authentication doesn't mean your app has authorization. You still need to check permissions in your API routes. --- ### How do I handle SOC 2 when my database is on Supabase or PlanetScale? *Keywords: Supabase SOC 2, PlanetScale SOC 2, managed database compliance* *Source: https://screenata.com/resources/answers/how-do-i-handle-soc-2-when-my-database-is-on-supabase-or-planetscale* ## Inherited vs. Your Controls Managed database providers handle infrastructure security (physical servers, network isolation, patching). You handle configuration and access security. | Responsibility | Provider (Supabase/PlanetScale) | You | |---------------|------|-----| | Physical security | Yes | No | | Network infrastructure | Yes | No | | Database engine patching | Yes | No | | Encryption at rest | Yes (enabled by default) | Verify it's enabled | | Access controls | API key/connection management | Who has credentials, how they're stored | | Row-level security | Provides the feature | Configure and enforce policies | | Backup configuration | Provides the feature | Verify backup schedule and retention | | Connection security | SSL/TLS available | Ensure SSL is required, not optional | ## Evidence for Supabase | Evidence | Where to Find It | |----------|-----------------| | Supabase SOC 2 report | Request from Supabase (available for Pro+ plans) | | Encryption at rest | Database settings showing encryption enabled | | Row-Level Security | RLS policies on sensitive tables | | API key management | Dashboard showing API keys (anon vs. service role) | | Connection pooling | Supavisor configuration | | Access controls | Team member list and roles | | Backup settings | Point-in-time recovery configuration | ## Evidence for PlanetScale | Evidence | Where to Find It | |----------|-----------------| | PlanetScale SOC 2 report | Request from PlanetScale | | Branch-based schema changes | Deploy requests showing schema change reviews | | Access controls | Organization member list and permissions | | Connection security | Connection strings using SSL | | Audit logging | Query insights and access logs | ## Common Gaps - **Exposed API keys:** Supabase anon keys in client-side code without RLS. Ensure RLS policies protect sensitive data. - **Direct database access:** Engineers connecting to production via GUI tools without audit logging. Restrict direct access or log all connections. - **Missing backups:** Verify that automated backups are enabled and test a restore at least once. - **Shared credentials:** Multiple engineers using the same database credentials. Use individual connection credentials where possible. --- ### How do I handle SOC 2 when my team has no security background? *Keywords: SOC 2 without security team, SOC 2 non-technical team, SOC 2 no CISO* *Source: https://screenata.com/resources/answers/how-do-i-handle-soc-2-when-my-team-has-no-security-background* ## You Don't Need a Security Expert SOC 2 doesn't require a CISO or security engineer. It requires: 1. Reasonable security controls for your size and risk 2. Policies that describe those controls accurately 3. Evidence that the controls work Most engineering teams already practice good security habits (code reviews, MFA, access controls). SOC 2 just asks you to write it down and prove it. ## What You Actually Need to Know | Topic | What to Learn | How Long | |-------|-------------|----------| | Trust Services Criteria | Which criteria apply to your audit | 1 hour | | Your control environment | What security practices you already have | 2 hours | | Evidence requirements | What auditors will ask for | 2 hours | | Policy writing | How to describe your controls in SOC 2 format | 4 hours | ## The Learning Path ### Step 1: Understand the Framework Read the AICPA Trust Services Criteria document (free online). Focus on the Security category, that's the baseline for every SOC 2 audit. ### Step 2: Inventory Your Controls List what you already do: code reviews via PRs, MFA on email, encrypted database, cloud hosting. You'll be surprised how much is already in place. ### Step 3: Identify Gaps Common gaps for teams without security background: - No formal access review process - No incident response plan - No vendor management documentation - No background checks for employees - No security awareness training ### Step 4: Fill the Gaps Each gap takes 2-4 hours to address. Write an access review process. Draft an incident response plan based on how you'd actually respond to a breach. Start conducting background checks for new hires. ## One Warning Don't fake expertise you don't have. If your auditor asks about your security program and you recite memorized compliance jargon, they'll probe deeper. Instead, be straightforward about what you do and how you do it. Auditors prefer honest, simple answers over polished but hollow ones. --- ### How do I handle the SOC 2 readiness gap when I don't have all controls yet? *Keywords: SOC 2 gap remediation, missing controls SOC 2, compliance gap plan* *Source: https://screenata.com/resources/answers/how-do-i-handle-the-soc-2-readiness-gap-when-i-dont-have-all-controls-yet* ## Assessing Your Gaps A readiness gap is any SOC 2 control you haven't implemented yet. Common gaps for startups: | Gap | Risk Level | Time to Fix | |-----|-----------|-------------| | No MFA enforcement | High | 1 hour | | No branch protection | High | 30 minutes | | No incident response plan | High | 4 hours | | No formal access reviews | Medium | 2 hours | | No background checks | Medium | 1 week (per hire) | | No MDM/endpoint management | Medium | 1 day | | No vendor management process | Low | 3 hours | | No security training program | Low | 1 day | ## Prioritization Strategy Fix gaps in this order: ### Priority 1: Controls that block the audit MFA, branch protection, encryption, logging, these are table stakes. Without them, no auditor will proceed. ### Priority 2: Documentation gaps Missing policies are easy to fix but take time. Start writing your information security policy, access control policy, and incident response plan immediately. ### Priority 3: Process gaps Access reviews, vendor assessments, and training programs take time to establish. Get at least one cycle completed before the audit. ## The Type I Strategy If you have significant gaps, start with a SOC 2 Type I audit. Type I evaluates controls at a single point in time, the audit date. This means you only need controls *implemented* by the audit date, not operating for months. Timeline: 1. Weeks 1-4: Implement all missing controls 2. Weeks 5-6: Write policies describing the controls 3. Week 7-8: Collect evidence, run self-assessment 4. Week 9: Engage auditor for Type I After passing Type I, begin your Type II observation period with all controls already in place. ## Don't Hide Gaps If you find a gap during the audit, don't try to hide it. Discuss it with your auditor. A documented plan to remediate a gap (with timeline and owner) is better than a poorly implemented control that fails testing. --- ### How do I keep my SOC 2 certification going after the first audit? *Keywords: SOC 2 renewal, maintaining SOC 2, SOC 2 Type 2 ongoing* *Source: https://screenata.com/resources/answers/how-do-i-keep-my-soc-2-certification-going-after-the-first-audit* ## SOC 2 Is Not a One-Time Certificate SOC 2 reports expire. Type I is a point-in-time snapshot. Type II covers a specific period (usually 12 months). Enterprise customers expect your report to be current, typically less than 12 months old. ## The Annual Cycle | Month | Task | |-------|------| | Ongoing | Maintain controls (branch protection, MFA, access management) | | Quarterly | Run access reviews, update vendor management records | | Month 9 | Begin collecting evidence for the upcoming audit | | Month 10 | Engage auditor, confirm scope | | Month 11-12 | Audit fieldwork | | After audit | Receive report, distribute to customers | ## What Gets Easier | First Audit | Subsequent Audits | |-------------|-------------------| | Write all policies from scratch | Update existing policies | | Set up all controls | Maintain existing controls | | Learn the process | Already know what to expect | | 40-80 hours of evidence collection | 10-20 hours (most is repeatable) | | Higher auditor cost (first-time setup) | Lower auditor cost (renewal rate) | ## What Requires Ongoing Attention 1. **Access reviews:** Quarterly reviews must happen consistently. Set calendar reminders. 2. **Policy updates:** When you change cloud providers, add new tools, or restructure teams, update your policies. 3. **Evidence collection:** Don't wait until month 11. Collect evidence continuously or automate it. 4. **New employee onboarding:** Every new hire needs security training, background check, and proper access provisioning. 5. **Vendor management:** Annually review critical vendors and collect their updated SOC 2 reports. ## Common Second-Year Mistakes - **Assuming last year's evidence works.** Auditors want current evidence, not screenshots from 12 months ago. - **Letting controls lapse.** Branch protection gets disabled "temporarily" and never re-enabled. - **Skipping access reviews.** Easy to forget when there's no active audit. One missed quarter is an exception. - **Not updating the system description.** If you migrated from Heroku to Vercel, the system description needs to reflect that. --- ### How do I know if my startup actually needs SOC 2? *Keywords: do I need SOC 2, SOC 2 requirements, when to get SOC 2* *Source: https://screenata.com/resources/answers/how-do-i-know-if-my-startup-actually-needs-soc-2* ## Do You Actually Need SOC 2? Not every startup does. SOC 2 solves a specific problem: enterprise buyers will not approve you as a vendor without it. If that is not happening in your sales cycle, SOC 2 is premature. ## Signs You Need SOC 2 1. A prospect's security team has asked for your SOC 2 report 2. You are losing deals or facing long security review cycles 3. You are selling to companies with 200+ employees 4. Your customers operate in finance, healthcare, or government 5. You handle sensitive customer data (PII, financial records, health data) 6. RFPs require SOC 2 as a qualification criterion 7. Competitors in your space already have SOC 2 ## Signs You Do Not Need SOC 2 Yet | Situation | Why SOC 2 Can Wait | |-----------|-------------------| | Selling only to SMBs (under 100 employees) | SMBs rarely require formal compliance reports | | Pre-revenue or pre-product | No customers to protect yet | | Consumer product (B2C) | Consumer buyers do not ask for SOC 2 | | Internal tool with no external data | No external customer data in scope | | No enterprise sales pipeline | No buyer requiring it | ## The Decision Framework Ask yourself two questions: 1. **Have any prospects or customers asked for SOC 2?** If yes, start now. 2. **Are you planning to sell to mid-market or enterprise within 12 months?** If yes, start planning. If the answer to both is no, invest your time elsewhere. SOC 2 takes 2–3 months from start to report. You can always start when the first request comes in. ## When to Start Preparing The ideal time is when you close your first few mid-market deals and see enterprise prospects in your pipeline. Starting 3 months before you need the report gives you enough runway. Screenata can accelerate this timeline, getting startups audit-ready in weeks rather than months. --- ### How do I negotiate auditor fees for SOC 2? *Keywords: SOC 2 auditor pricing, negotiate audit cost, affordable SOC 2 auditor* *Source: https://screenata.com/resources/answers/how-do-i-negotiate-auditor-fees-for-soc-2* ## Can You Negotiate SOC 2 Auditor Fees? Yes. SOC 2 auditor fees are not fixed, they are based on estimated effort. Anything you do to reduce the auditor's workload translates to lower fees. And like any professional service, getting competitive quotes gives you negotiating power. ## Negotiation Strategies ## What Drives Auditor Pricing Auditors estimate fees based on: 1. **Hours of fieldwork**, More controls and systems = more testing hours 2. **Number of walkthroughs**, More people to interview = more time 3. **Evidence quality**, Disorganized evidence takes longer to review 4. **Remediation risk**, Companies likely to need re-testing cost more 5. **Firm overhead**, Larger firms have higher overhead baked into fees ## How to Get the Lowest Fee The single most effective way to reduce your auditor fee is to be well-prepared. When you submit organized, complete evidence on day one of fieldwork, the auditor spends less time chasing information. This directly reduces their hours and your bill. Screenata organizes your evidence by control area and maps it to Trust Services Criteria before your auditor begins, making your engagement faster and cheaper. --- ### How do I organize my SOC 2 evidence library before the audit? *Keywords: SOC 2 evidence library, evidence organization, audit documentation* *Source: https://screenata.com/resources/answers/how-do-i-organize-my-soc-2-evidence-library-before-the-audit* ## How to Structure Your Evidence Library ### Option A: By Control Criteria (Recommended) ``` SOC2-Evidence/ ├── CC1 - Control Environment/ │ ├── info-security-policy.pdf │ ├── org-chart.png │ └── security-training-records.csv ├── CC6 - Access Controls/ │ ├── CC6.1-mfa-enforcement.png │ ├── CC6.1-user-list-google.png │ ├── CC6.1-user-list-github.png │ ├── CC6.1-access-review-Q1.pdf │ └── CC6.1-access-review-Q2.pdf ├── CC7 - Monitoring/ │ ├── CC7.2-cloudwatch-alarms.png │ ├── CC7.2-sentry-config.png │ └── CC7.3-incident-response-plan.pdf ├── CC8 - Change Management/ │ ├── CC8.1-branch-protection.png │ ├── CC8.1-ci-pipeline.png │ └── CC8.1-sample-prs/ ``` ### Option B: By Evidence Type (Less Ideal) Organizing by type (screenshots, policies, logs) makes it harder for auditors to find what they need for each control. ## The Evidence Index Create a spreadsheet mapping each piece of evidence to its control: | Control | Evidence Description | File Name | Date Captured | |---------|---------------------|-----------|---------------| | CC6.1 | MFA enforcement - Google Workspace | CC6.1-mfa-google.png | 2026-03-01 | | CC6.1 | GitHub org member list | CC6.1-github-members.png | 2026-03-01 | | CC8.1 | Branch protection settings | CC8.1-branch-protection.png | 2026-03-01 | ## File Naming Convention Use a consistent naming pattern: `[Control]-[Description]-[Date].[ext]` Examples: - `CC6.1-mfa-enforcement-google-2026-03.png` - `CC8.1-branch-protection-main-2026-03.png` - `CC7.3-incident-response-plan-v2.pdf` ## Tips - **Use Google Drive or Notion**, not scattered local folders. The auditor needs access. - **Version your policies.** Include version number and last review date in the filename. - **Timestamp everything.** Every screenshot should have a visible date. - **Pre-share with the auditor.** Give them read access to your evidence library before the audit starts. This saves time during walkthroughs. - **Keep it current.** Remove outdated evidence and replace with fresh captures before the audit. --- ### How do I prepare for a SOC 2 audit in 30 days? *Keywords: SOC 2 audit preparation, fast SOC 2, SOC 2 readiness 30 days* *Source: https://screenata.com/resources/answers/how-do-i-prepare-for-a-soc-2-audit-in-30-days* ## Is 30 Days Realistic? For a SOC 2 Type I audit (point-in-time), yes, if your startup already has basic security practices like code reviews, cloud hosting, and MFA available. You're formalizing what you already do, not building from scratch. For Type II, 30 days isn't enough. Type II requires an observation period (3-12 months) of controls operating consistently. ## The 30-Day Plan ### Days 1-5: Technical Controls | Task | Time | |------|------| | Enforce MFA on Google Workspace, GitHub, AWS | 2 hours | | Enable GitHub branch protection on main | 30 minutes | | Enable CloudTrail or equivalent logging | 1 hour | | Deploy MDM on company devices | 3 hours | | Review and restrict admin access across systems | 2 hours | ### Days 6-15: Documentation Write the seven core policy documents: - Day 6-7: Information Security Policy - Day 8-9: Access Control Policy + Change Management Policy - Day 10-11: Incident Response Plan - Day 12-13: Risk Assessment + Vendor Management Policy - Day 14-15: System Description Each document should take 2-4 hours if you're describing your actual systems (not writing from scratch with no reference point). ### Days 16-25: Evidence Collection Capture evidence for each control area: - Access controls: MFA settings, user lists, role assignments - Change management: branch protection, sample PRs - Monitoring: alerting configuration, log settings - Data protection: encryption settings, backup configs - Vendor management: list of critical vendors with their SOC 2 reports ### Days 26-30: Self-Assessment and Gaps Review everything against TSC criteria. Fix any gaps found. Organize evidence by control for easy auditor access. ## What to Skip - Penetration testing (not required for SOC 2, though useful) - Building a security dashboard - Perfect documentation, good enough is good enough for Type I ## Accelerating with AI Screenata can compress days 6-25 into a few days by reading your codebase, generating policies, and collecting evidence automatically. The 30-day plan becomes a 10-day plan. --- ### How do I prove change management for SOC 2 using GitHub PRs? *Keywords: SOC 2 change management GitHub, GitHub PR evidence, CC8.1 GitHub* *Source: https://screenata.com/resources/answers/how-do-i-prove-change-management-for-soc-2-using-github-prs* ## Why GitHub PRs Are Great SOC 2 Evidence GitHub pull requests naturally create the audit trail that CC8.1 requires. Each PR contains: - **Description:** What changed and why - **Diff:** Exactly what code was modified - **Review:** Comments and approval from a peer - **CI checks:** Automated test results - **Merge timestamp:** When the change went to production This is better evidence than most enterprise change management systems produce. ## Setting Up GitHub for CC8.1 ### Branch Protection (Required) Configure branch protection on your main branch: - Require pull request reviews before merging (minimum 1 reviewer) - Require status checks to pass (your CI pipeline) - Prevent force pushes to main - Do not allow bypassing the above settings (even for admins) ### CI Pipeline Ensure GitHub Actions (or your CI tool) runs on every PR: - Unit tests - Linting or type checking - Build verification ### PR Template (Recommended) Create a PR template that prompts for: - Summary of changes - Type of change (feature, bugfix, refactor) - Testing performed - Related ticket or issue number ## Evidence to Collect | Evidence | How to Get It | |----------|--------------| | Branch protection settings | Screenshot of GitHub settings page for main branch | | Sample PRs with reviews | Links to 25+ PRs from the audit period showing approval | | CI pipeline configuration | GitHub Actions YAML file or screenshot | | Deployment records | Vercel/deployment platform showing deploys triggered by merges | ## Handling Edge Cases **Direct commits to main:** These will show up in audit sampling. Prevent them with branch protection rules. **Hotfixes:** Document emergency changes with a post-deployment PR explaining the urgency and why normal review was bypassed. **Admin bypasses:** Set branch protection to "Do not allow bypassing", even for admins. This eliminates the temptation and the audit risk. --- ### How do I prove compliance to enterprise customers during sales? *Keywords: compliance sales enablement, enterprise security review, trust center* *Source: https://screenata.com/resources/answers/how-do-i-prove-compliance-to-enterprise-customers-during-sales* ## The Sales Problem Enterprise deals stall at the security review. The buyer's InfoSec team sends a questionnaire, your team scrambles to answer it, and weeks pass in back-and-forth. Every day in review is a day the deal isn't closing. ## The Compliance Sales Stack ### Tier 1: Trust Page (Always Available) Create a public page at `/security` or `/trust` covering: - Security practices overview - SOC 2 report status and date - Encryption standards - Data handling practices - Compliance certifications - Contact for security questions ### Tier 2: SOC 2 Report (Under NDA) Share your report through a secure link after the buyer signs an NDA or mutual NDA. Most enterprise security teams accept a current SOC 2 report in place of 60-80% of their questionnaire. ### Tier 3: Pre-Built Questionnaire Answers Maintain a bank of answers to common security questions. Most questionnaires overlap significantly. Pre-answering the standard questions lets you respond in 1-2 days instead of 1-2 weeks. ### Tier 4: Compliance Documentation Pack For high-value deals, offer a documentation pack: - SOC 2 report - System description - Data processing agreement - Subprocessor list - Security white paper ## Impact on Sales Cycles | Sales Approach | Security Review Duration | Deal Impact | |---------------|------------------------|-------------| | No compliance program | 3-6 weeks (or deal lost) | Deals stall or die | | SOC 2 + trust page | 3-5 days | Deals close on schedule | | SOC 2 + pre-built answers + trust page | 1-2 days | Minimal sales friction | ## Getting Started 1. **Publish a trust page**, even before SOC 2, list your security practices 2. **Get SOC 2**, the single biggest accelerator for enterprise sales 3. **Build a questionnaire answer bank**, save and reuse every questionnaire response 4. **Create a compliance documentation pack**, ready to share with high-value prospects Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). --- ### How do I prove endpoint security for SOC 2 as a remote-first startup? *Keywords: endpoint security SOC 2, MDM evidence, remote team compliance* *Source: https://screenata.com/resources/answers/how-do-i-prove-endpoint-security-for-soc-2-as-a-remote-first-startup* ## What Auditors Check for Endpoints For remote-first companies, employee laptops are part of your SOC 2 scope. Auditors want proof that these devices are secured, even when they're connecting from home offices and coffee shops. | Control | What Auditors Want | |---------|-------------------| | Disk encryption | FileVault (Mac) or BitLocker (Windows) enabled on all devices | | OS updates | Automatic updates enabled, no devices running outdated OS | | Screen lock | Auto-lock after inactivity (5-15 minutes) | | Antivirus/malware | Endpoint protection active (Macs: built-in + MDM, Windows: Defender + MDM) | | Password manager | Company-managed password manager deployed | | MDM enrollment | All company devices enrolled in MDM | ## MDM Options for Startups ## Evidence to Collect ### From MDM Dashboard 1. **Device list:** Screenshot showing all enrolled devices with compliance status 2. **Encryption status:** Report showing FileVault/BitLocker enabled on all devices 3. **OS version:** Report showing all devices on supported OS versions 4. **Security settings:** Screenshot of MDM profile enforcing screen lock, firewall, etc. ### From Your Policy - Endpoint security policy stating requirements - BYOD policy (if applicable) defining minimum security standards - Onboarding process including MDM enrollment step ## Without MDM (Budget Alternative) If MDM isn't in your budget yet: 1. Require employees to enable FileVault/BitLocker and submit screenshots 2. Require screen lock configuration (screenshot of settings) 3. Document the requirement in your security policy 4. Conduct quarterly checks via screenshare or screenshots This is less robust than MDM but can satisfy an auditor if you document the process and follow it consistently. --- ### How do I prove feature flag changes for SOC 2 change management? *Keywords: feature flags SOC 2, LaunchDarkly evidence, configuration changes SOC 2* *Source: https://screenata.com/resources/answers/how-do-i-prove-feature-flag-changes-for-soc-2-change-management* ## Why Feature Flags Matter for SOC 2 Feature flags modify application behavior without deploying new code. From a SOC 2 perspective, flipping a flag in production is equivalent to a code change, it alters how the system operates. Your change management policy (CC8.1) should cover flag changes. Auditors are increasingly aware of feature flags. If they ask "how do changes reach production?" and you only describe your GitHub PR workflow, they'll ask about other change vectors, including feature flags. ## Evidence to Provide | Evidence | Source | |----------|--------| | Flag change audit log | LaunchDarkly audit log, Unleash event log, or custom logging | | Approval workflow | Screenshots showing approval requirements for production flags | | Flag inventory | List of active production flags with owners | | Change history | Sample flag changes showing who, what, when | | Rollback capability | Evidence that flags can be quickly reverted | ## Change Management Controls for Flags ### Minimum Controls 1. **Audit logging:** Every flag change is logged with timestamp, user, old value, new value 2. **Access control:** Not everyone can change production flags, limit to specific roles 3. **Documentation:** Significant flag changes have a description or ticket reference ### Recommended Controls 4. **Approval workflow:** Production flag changes require peer approval (LaunchDarkly supports this) 5. **Staged rollout:** Flags are toggled in staging before production 6. **Review cadence:** Stale flags are reviewed and removed quarterly ## Platform-Specific Evidence **LaunchDarkly:** Export the audit log showing flag changes during the observation period. Screenshot approval workflows and role-based access settings. **Custom flags (database or config file):** Treat flag changes like code changes, require a PR for configuration file changes, or log database updates to an audit table. ## Common Gap Feature flag platforms often have weaker access controls than your code repository. While your GitHub requires PR reviews, your LaunchDarkly might let any team member toggle production flags. Address this asymmetry before the audit. --- ### How do I prove role-based access control works for SOC 2? *Keywords: RBAC evidence SOC 2, prove access controls, CC6.1 evidence* *Source: https://screenata.com/resources/answers/how-do-i-prove-role-based-access-control-works-for-soc-2* ## What Auditors Need to See RBAC evidence for SOC 2 CC6.1 proves that your systems enforce different access levels based on job function. Auditors test three things: 1. **Roles are defined.** You have documented roles with specific permissions. 2. **Users are assigned correctly.** Each user has the role matching their job function. 3. **Access is restricted.** Users in lower roles can't access admin functions. ## Evidence to Prepare | Evidence Type | What to Capture | |---------------|----------------| | Role definitions | Document listing each role and its permissions | | User-role mapping | Screenshot of user list showing role assignments (GitHub, AWS, your app) | | Permission matrix | Table showing which roles can access which resources | | Access restriction proof | Screenshot showing a non-admin user can't access admin settings | | Access review | Quarterly review confirming users are in correct roles | ## RBAC Across Your Stack Show RBAC evidence for each critical system: **GitHub:** Organization member roles (admin, member), team-level permissions, repository access levels. **AWS/Cloud:** IAM groups or roles with specific policy attachments. Show that not everyone has `AdministratorAccess`. **Your Application:** If your app has roles (admin, user, viewer), show the code or configuration that enforces them, and a screenshot of the admin panel showing user role assignments. **Google Workspace:** Show admin vs. user roles and which privileges each has. ## Common Mistakes - **Everyone is admin.** Fix this before the audit. Even two roles (admin, developer) demonstrates least privilege. - **No documentation.** Auditors need a written list of roles and their intended permissions, not just system screenshots. - **Inconsistent assignments.** If your sales intern has admin access to AWS, that contradicts least privilege. ## Quick Wins If you don't have formal RBAC today, start with: 1. Create an "admin" and "member" role in each system 2. Restrict admin to 2-3 people (CTO + founding engineers) 3. Document the roles and who has each 4. Review assignments quarterly --- ### How do I prove SOC 2 compliance for a Python Django or Rails app? *Keywords: Django SOC 2, Rails SOC 2, SOC 2 web framework* *Source: https://screenata.com/resources/answers/how-do-i-prove-soc-2-compliance-for-a-python-django-or-rails-app* ## Framework Security Features as SOC 2 Evidence Both Django and Rails include security features that map to SOC 2 controls. Document these in your system description: | Security Feature | Django | Rails | SOC 2 Control | |------------------|--------|-------|---------------| | CSRF protection | Built-in middleware | Built-in token verification | CC6.1 | | SQL injection prevention | ORM parameterization | ActiveRecord parameterization | CC6.1 | | XSS protection | Template auto-escaping | ERB auto-escaping | CC6.1 | | Session management | Django sessions framework | Action Dispatch sessions | CC6.1 | | Password hashing | PBKDF2 by default | bcrypt by default | CC6.1 | | Clickjacking protection | X-Frame-Options middleware | X-Frame-Options header | CC6.1 | ## Application-Level Evidence Beyond framework defaults, prove your specific implementation: ### Authentication - Screenshot of your login flow showing MFA (if implemented) - Code or configuration showing authentication method (Django Allauth, Devise, etc.) - Session timeout configuration ### Authorization - Your permission model (Django groups/permissions, Pundit/CanCanCan policies) - Screenshot showing different access levels for different user roles - API endpoint authorization checks ### Data Protection - Database encryption configuration (RDS, PostgreSQL native) - Environment variable management (no secrets in code) - Data handling in views/controllers (what data is logged, what's filtered) ## Deployment Evidence | Evidence | Django Typical Setup | Rails Typical Setup | |----------|---------------------|-------------------| | CI/CD pipeline | GitHub Actions → Heroku/AWS | GitHub Actions → Heroku/AWS | | Test suite | pytest results | RSpec/Minitest results | | Code review | GitHub PR approvals | GitHub PR approvals | | Dependency scanning | pip-audit, Safety | Bundler-audit, Brakeman | ## Tips for Django/Rails Startups - **Run a security scanner** before the audit. Use `bandit` (Python) or `brakeman` (Rails) to catch common issues. - **Document your middleware/rack stack.** Show the auditor which security middleware is active. - **Check `settings.py` / environment config.** Ensure DEBUG=False, SECURE_SSL_REDIRECT=True, and similar production settings are documented. --- ### How do I respond to a security questionnaire without a SOC 2 report? *Keywords: security questionnaire no SOC 2, vendor security review, pre-SOC 2 sales* *Source: https://screenata.com/resources/answers/how-do-i-respond-to-a-security-questionnaire-without-a-soc-2-report* ## The Situation An enterprise prospect sends you a security questionnaire, 50-100 questions about your security practices. You don't have a SOC 2 report to point to. Here's how to handle it. ## Response Strategy ### Be Specific, Not Generic Bad: "We use industry-standard encryption." Good: "All data at rest is encrypted using AES-256 via Supabase PostgreSQL. Data in transit is encrypted via TLS 1.3 on all Vercel endpoints." ### Be Honest About Gaps Bad: "Yes, we conduct annual penetration testing." (You don't.) Good: "We have not conducted a formal penetration test yet. We use automated vulnerability scanning via Dependabot and plan to conduct our first pentest in Q3 2026." ### Attach Evidence For key questions, attach supporting screenshots: - MFA enforcement settings - Encryption configuration - Branch protection rules - User access list showing role-based access ## Common Questions and How to Answer | Question | How to Answer Without SOC 2 | |----------|---------------------------| | "Do you have a SOC 2 report?" | "We are pursuing SOC 2 Type I, targeting [date]. In the interim, here are our current security controls." | | "How do you handle access management?" | Describe your exact process, SSO provider, MFA enforcement, access review cadence | | "How do you manage code changes?" | "All changes require GitHub PR with peer review and CI checks before merge to main" | | "Do you have an incident response plan?" | Provide the plan if you have one; if not, describe how you'd respond | | "Where is data stored?" | Name your providers, regions, and encryption settings | ## Tips - **Respond within 1 week.** Slow responses signal organizational immaturity. - **Be consistent.** If you send a questionnaire to one customer, save your answers for the next one. - **Mention your SOC 2 timeline.** "We're pursuing SOC 2 and expect our report by [date]" shows commitment. - **Create a trust page.** Publish your security practices on your website so prospects can self-serve basic information. - **Use a tool like Screenata** to accelerate your SOC 2 timeline so you can replace questionnaires with a report sooner. --- ### How do I reuse SOC 2 evidence for ISO 27001? *Keywords: SOC 2 to ISO 27001, evidence reuse, dual compliance* *Source: https://screenata.com/resources/answers/how-do-i-reuse-soc-2-evidence-for-iso-27001* ## What Reuses Directly | SOC 2 Evidence | ISO 27001 Control | Reuse? | |---------------|-------------------|--------| | MFA enforcement screenshots | A.9.4 (Access control) | Direct reuse | | User access reviews | A.9.2 (User access management) | Direct reuse | | GitHub branch protection | A.14.2 (Development security) | Direct reuse | | PR review evidence | A.14.2 (Change management) | Direct reuse | | Encryption settings | A.10.1 (Cryptographic controls) | Direct reuse | | Incident response plan | A.16.1 (Incident management) | Direct reuse | | Risk assessment | Clause 6.1 (Risk assessment) | Partial, may need ISO format | | Vendor management records | A.15.1 (Supplier relations) | Direct reuse | | Security training records | A.7.2 (Awareness) | Direct reuse | | System monitoring evidence | A.12.4 (Logging/monitoring) | Direct reuse | ## What You Need to Add for ISO 27001 | ISO 27001 Requirement | What to Create | SOC 2 Equivalent | |----------------------|----------------|-------------------| | Information Security Management System (ISMS) | Formal ISMS document describing scope, policies, processes | No direct equivalent, new document needed | | Statement of Applicability (SoA) | Document listing all 114 Annex A controls with justification for including/excluding each | No direct equivalent, new document needed | | Management review | Minutes from management review meeting covering ISMS performance | SOC 2 has no formal management review requirement | | Continual improvement | Evidence of improvements made based on incidents, reviews, or audits | No formal requirement in SOC 2 | | Internal audit | Results of your internal ISO 27001 audit | SOC 2 doesn't require internal audit | ## The Dual-Compliance Approach 1. **Start with SOC 2.** Get your controls, policies, and evidence library established. 2. **Map SOC 2 controls to ISO 27001 Annex A.** Use a mapping spreadsheet to identify which controls are already covered. 3. **Write additional ISO documents.** Focus on ISMS, SoA, and management review, the uniquely ISO requirements. 4. **Reuse all compatible evidence.** Point your ISO assessor to the same evidence library your SOC 2 auditor uses. 5. **Engage an ISO certification body.** The assessment builds on your existing control foundation. ## Timeline If you already have SOC 2: 2-4 months to add ISO 27001. Most of the work is documentation (ISMS, SoA), not new controls. --- ### How do I run a SOC 2 readiness assessment myself? *Keywords: DIY SOC 2 readiness, self-assessment SOC 2, SOC 2 gap analysis* *Source: https://screenata.com/resources/answers/how-do-i-run-a-soc-2-readiness-assessment-myself* ## How Do I Assess Readiness Without a Consultant? You can run your own readiness assessment using the AICPA's Trust Services Criteria as a checklist. Walk through each criterion, document what you already have in place, identify gaps, and create a remediation plan. This takes 1–2 weeks and costs nothing except your time. ## Step-by-Step Self-Assessment 1. **Define your scope**, List the systems that process customer data (cloud accounts, databases, applications, SaaS tools) 2. **Map existing controls**, For each system, document what security controls exist today 3. **Check against criteria**, Compare your controls to each Common Criteria point (CC1 through CC9) 4. **Identify gaps**, Mark where you have no control, no documentation, or no evidence 5. **Prioritize remediation**, Fix high-impact gaps first (access controls, change management, encryption) 6. **Document everything**, Write down what you found and what you plan to fix ## Key Areas to Evaluate | Criteria | Key Questions | Common Gap | |----------|--------------|------------| | CC1 (Control environment) | Is there a security policy? Who owns security? | No written policy | | CC2 (Communication) | Do employees know security expectations? | No security awareness program | | CC3 (Risk assessment) | Have you identified and documented risks? | No risk register | | CC5 (Control activities) | Are controls implemented for each risk? | Controls exist but are not documented | | CC6 (Logical access) | Is access restricted and reviewed? | No formal access review process | | CC7 (System operations) | Do you monitor for security events? | No centralized logging | | CC8 (Change management) | Are changes approved before deployment? | Direct pushes to production | | CC9 (Risk mitigation) | Do you assess vendor and third-party risk? | No vendor management process | ## What to Do With the Results Your gap report becomes your SOC 2 project plan. Rank each gap by effort (low/medium/high) and impact (blocks audit / creates risk / nice to have). Fix the audit-blocking items first. Screenata automates this process by analyzing your codebase and infrastructure, producing a readiness report with specific remediation steps in days. --- ### How do I run a user access review for SOC 2? *Keywords: user access review, UAR SOC 2, access certification, access review process* *Source: https://screenata.com/resources/answers/how-do-i-run-a-user-access-review-for-soc-2* ## What Is a User Access Review? A user access review (UAR) is a periodic check where you verify that everyone who has access to your systems still needs it and has the right level of access. For SOC 2, auditors expect at least quarterly reviews. ## How to Run One ### Step 1: List Your Critical Systems Identify every system that handles customer data or production infrastructure: - Google Workspace / Okta (identity provider) - AWS / GCP / Azure (cloud infrastructure) - GitHub (code repository) - Database (Supabase, PlanetScale, RDS) - Application admin panel - Monitoring tools (Sentry, DataDog) ### Step 2: Export User Lists For each system, export the list of active users with their roles. Screenshot the admin panel or download the user CSV. ### Step 3: Review Each Account For every user, verify: | Check | Action | |-------|--------| | Still employed? | Remove access for former employees | | Still in this role? | Adjust permissions if role changed | | Needs this level? | Downgrade admin to member if full access isn't required | | Active account? | Disable dormant accounts (no login in 90+ days) | ### Step 4: Document the Review Record: date of review, who performed it, systems reviewed, changes made, and any exceptions noted. Save this document, the auditor will ask for it. ### Step 5: Make Changes Remove or downgrade access immediately for any issues found. Don't just document the finding, fix it. ## Evidence to Keep - Screenshots of user lists with dates - A summary document listing review date, reviewer, and findings - Records of any access changes made as a result - Calendar invite showing the quarterly cadence ## Timing Set a quarterly calendar reminder. The whole review takes 1-2 hours for a team under 50 people. The cost of not doing it: an audit finding that's easy to prevent. --- ### How do I scope my SOC 2 audit to keep it manageable? *Keywords: SOC 2 scoping, SOC 2 scope, minimize SOC 2 scope* *Source: https://screenata.com/resources/answers/how-do-i-scope-my-soc-2-audit-to-keep-it-manageable* ## How Do I Keep SOC 2 Scope Small? SOC 2 scope determines how much work you do. A larger scope means more controls, more evidence, and a longer audit. The key is including only what matters, the systems and criteria that your customers and auditor actually need to see. ## Scoping Decisions | Decision | Smaller Scope | Larger Scope | |----------|--------------|--------------| | Trust Services Criteria | Security only | Security + Availability + Confidentiality | | Systems included | Production environment only | Production + staging + internal tools | | Cloud accounts | One AWS/GCP account | Multiple accounts across regions | | Applications | Customer-facing app only | All internal applications | | People | Engineering + leadership | Entire company | ## Three Rules for Scoping 1. **Include only systems that touch customer data.** Your internal Slack, HR tools, and marketing stack are typically out of scope. Focus on your production infrastructure, application, and the SaaS tools that access customer data. 2. **Start with Security only.** Do not add Availability, Processing Integrity, Confidentiality, or Privacy unless a specific customer requires it in writing. 3. **Draw your boundary at the infrastructure level.** If you use Vercel or AWS, your boundary starts at your configuration layer, not at the physical data center. Reference your cloud provider's SOC 2 report for infrastructure controls below your boundary. ## Common Scoping Mistakes - Including staging and development environments (rarely needed) - Adding every SaaS tool the company uses (only include those that touch customer data) - Scoping to all five Trust Services Criteria on the first audit - Including employee personal devices beyond basic MDM requirements ## How to Document Your Scope Create a simple system description that lists: - Which cloud accounts are in scope - Which applications process customer data - Which third-party tools are included - Which Trust Services Criteria you are auditing against - Which teams and roles are in scope Screenata helps define your scope by analyzing your codebase and infrastructure to identify which systems process customer data and which controls apply. --- ### How do I take screenshots that SOC 2 auditors will accept? *Keywords: SOC 2 screenshot evidence, acceptable audit screenshots, SOC 2 screenshot tips* *Source: https://screenata.com/resources/answers/how-do-i-take-screenshots-that-soc-2-auditors-will-accept* ## What Auditors Want in a Screenshot A screenshot is the most common form of SOC 2 evidence. Auditors accept screenshots when they can answer three questions from the image alone: 1. **What system is this?** (URL bar, page title, or header visible) 2. **What control is demonstrated?** (setting clearly shown) 3. **When was this captured?** (timestamp visible) ## Screenshot Best Practices | Do | Don't | |----|-------| | Include the browser URL bar | Crop to just the toggle or setting | | Show the date/time (system clock or page timestamp) | Capture without any time reference | | Use full-page or section captures | Take tiny, context-free crops | | Name files descriptively (e.g., "github-branch-protection-main-2026-03.png") | Name files "screenshot1.png" | | Capture production environments | Capture staging or test environments | | Include the logged-in user context | Leave ambiguity about which account | ## Common Screenshot Types | Control | What to Capture | |---------|----------------| | MFA enforcement | Identity provider settings showing MFA required for all users | | Branch protection | GitHub settings page showing required reviews and status checks | | Encryption at rest | Database or storage settings showing encryption enabled | | Access controls | User list with role assignments visible | | Firewall rules | Security group or WAF configuration | | Backup settings | Backup configuration showing schedule and retention | ## How Many Screenshots? For a SOC 2 Type I audit, expect to provide 50-100 screenshots across all controls. For Type II, you'll need configuration screenshots plus population samples (e.g., 25 PRs showing reviewer approval). ## The Timestamp Problem The most common screenshot rejection is missing timestamps. Solutions: - Keep your system clock visible in the screenshot - Use browser extensions that overlay timestamps - Use the page's own "last modified" or audit log timestamps - Document the capture date in a separate evidence log ## Where Screenata Helps Screenata automates screenshot-based evidence collection by recording your application workflows with built-in timestamps, user context, and control metadata. Instead of manually navigating to each settings page and capturing screenshots, Screenata generates audit-ready evidence automatically. --- ### How do I validate that AI-written SOC 2 policies are accurate? *Keywords: AI policy review, validate AI compliance, AI policy accuracy* *Source: https://screenata.com/resources/answers/how-do-i-validate-that-ai-written-soc-2-policies-are-accurate* ## Why Validation Matters AI-generated policies from your codebase are significantly more accurate than templates, but they're not infallible. The AI may misinterpret a configuration, reference a tool you've since replaced, or miss a recent change. A 2-hour review catches these issues before the auditor does. ## The Validation Checklist ### 1. Tool References For every tool named in a policy, verify: - [ ] Is this tool still in use? - [ ] Is the specific feature or setting described still configured this way? - [ ] Have you migrated to a different tool since the AI analyzed your systems? ### 2. Access Control Claims - [ ] Does the MFA enforcement setting match what the policy describes? - [ ] Are the roles listed in the policy the same roles in your system? - [ ] Does the described RBAC match your actual permission model? ### 3. Change Management Claims - [ ] Is branch protection configured as the policy describes? - [ ] Does the CI pipeline run the checks listed in the policy? - [ ] Is the deployment process accurately described? ### 4. Data Protection Claims - [ ] Is encryption configured as described? - [ ] Are backup settings accurate? - [ ] Is the data flow description current? ## Common Issues to Watch For | Issue | Example | Fix | |-------|---------|-----| | Stale tool reference | Policy mentions Heroku, you moved to Vercel | Update the reference | | Over-stated controls | "All API routes require authentication" but some are public | Correct to "authenticated routes" | | Missing recent changes | New database added, not in policy | Add the new system | | Wrong cadence | Policy says "weekly" access reviews, you do quarterly | Correct the frequency | ## The Review Process 1. **Read each policy statement aloud.** Does it describe your actual practice? 2. **Spot-check configurations.** Open the admin panel for 3-4 named systems and verify settings match. 3. **Ask your engineers.** Share the change management and access control policies with your team. Does this match how they work? 4. **Flag uncertainties.** If you're unsure about a statement, check the system before the audit. Validation takes 2-3 hours but prevents audit findings that take days to remediate. --- ### How do I write a change management policy for SOC 2? *Keywords: SOC 2 change management policy, CC8.1 policy, change control policy* *Source: https://screenata.com/resources/answers/how-do-i-write-a-change-management-policy-for-soc-2* ## What Change Management Means for SOC 2 Change management (CC8.1) proves that changes to your systems don't happen randomly. Auditors want evidence that code changes are reviewed, approved, and deployed through a controlled process, and that your policy describes that process accurately. For most SaaS startups, change management is just your existing GitHub workflow, formalized into a policy. ## What to Include | Section | Content | |---------|---------| | Scope | Which systems the policy covers (production application, infrastructure, configurations) | | Change types | Standard changes (PRs), emergency changes (hotfixes), infrastructure changes | | Approval process | Who reviews and approves changes (e.g., one engineering peer) | | Testing | How changes are tested before production (CI pipeline, preview deployments) | | Deployment | How approved changes reach production (merge to main triggers Vercel deploy) | | Emergency changes | How hotfixes bypass normal process and what documentation is required after | | Rollback | How to revert a problematic change | ## Example Policy Statements - "All application code changes require a GitHub pull request with at least one approving review before merge to the main branch." - "Branch protection rules on the main branch enforce required reviews and prevent force pushes." - "Merging to main automatically triggers deployment to production via Vercel's GitHub integration." - "Emergency changes may bypass the standard review process. A post-deployment PR with review must be created within 24 hours, documenting the reason for the emergency change." ## What Auditors Look For Auditors will pull a sample of recent deployments and check: 1. Was there a PR for each deployment? 2. Did someone other than the author approve it? 3. Did automated tests run before merge? 4. Was the change linked to a ticket or description? If your policy says "two approvals required" but your GitHub settings only require one, that's a finding. Write the policy to match your actual settings. --- ### How do I write a SOC 2 policy when I'm not a compliance expert? *Keywords: SOC 2 policy non-expert, write SOC 2 policy without vCISO, DIY SOC 2 policy* *Source: https://screenata.com/resources/answers/how-do-i-write-a-soc-2-policy-when-im-not-a-compliance-expert* ## You Already Know More Than You Think If you can answer these questions, you can write SOC 2 policies: - How does someone get access to your production systems? - What happens when a developer wants to deploy code? - How would you respond if you discovered a data breach? - Who decides what vendors you use, and how do you vet them? SOC 2 policies are just formalized answers to these questions. ## Step-by-Step Approach ### Step 1: Document Reality Open a doc and describe what your team does today. Don't worry about SOC 2 language. Write: - "New engineers get AWS access from the CTO via IAM. They need a Slack request in #access-requests." - "All code goes through a PR on GitHub. We require one reviewer before merge." - "If something breaks in production, the on-call person gets a PagerDuty alert." ### Step 2: Add Structure Organize your descriptions into policy sections: | Your Description | SOC 2 Policy Section | |-----------------|---------------------| | How people get access | Access Control Policy | | How code gets deployed | Change Management Policy | | How you handle incidents | Incident Response Plan | | How you pick vendors | Vendor Management Policy | ### Step 3: Add the Missing Pieces Look for gaps: Do you have a formal access review process? Is MFA required everywhere? Do you have background checks for new hires? These are common gaps that you can address before the audit. ### Step 4: Use SOC 2 Language (Lightly) Swap casual language for slightly more formal phrasing. "We do code reviews" becomes "All code changes require peer review through GitHub pull requests." You don't need legal jargon, just clear, specific statements. ## The AI Alternative If the manual approach feels overwhelming, Screenata reads your codebase and cloud setup, then generates policies in proper SOC 2 format that reference your actual systems. You review and approve instead of writing from scratch. --- ### How do I write an access control policy for SOC 2? *Keywords: SOC 2 access control policy, CC6.1 policy, access management policy* *Source: https://screenata.com/resources/answers/how-do-i-write-an-access-control-policy-for-soc-2* ## What an Access Control Policy Covers Access control is one of the most heavily tested areas in a SOC 2 audit. Your policy maps to CC6.1 through CC6.8 and defines how your organization manages who can access what, from cloud infrastructure to your application code to customer data. ## Key Sections | Section | What to Document | |---------|-----------------| | Access provisioning | How new employees get system access | | Role-based access | What roles exist and what each can access | | Least privilege | How you limit access to what's needed | | MFA requirements | Which systems require multi-factor authentication | | Access revocation | How access is removed when someone leaves | | Access reviews | How often you review who has access and why | | Shared accounts | Your stance on shared credentials (ideally: prohibited) | ## Example Policy Statements - "All employees authenticate via Google Workspace SSO with hardware key MFA required." - "AWS console access is restricted to the CTO and senior engineers. Access is provisioned through IAM roles with least-privilege policies." - "When an employee leaves, their Google Workspace account is suspended within 4 hours by the CTO. This automatically revokes SSO access to all connected applications." - "Access reviews are conducted quarterly. The CTO reviews all active user accounts across Google Workspace, AWS, GitHub, and Supabase." ## What Auditors Test 1. **Provisioning:** Pick a recent hire, was access granted according to policy? 2. **Termination:** Pick a recent departure, was access revoked promptly? 3. **Access reviews:** Show evidence of your most recent quarterly review. 4. **MFA:** Verify MFA is enforced (not just available) across critical systems. 5. **Privilege levels:** Confirm that not everyone has admin access. ## Common Startup Mistakes - **Everyone is admin.** Early-stage startups often give all engineers full admin access. Before your audit, implement role-based access, even simple "admin" vs. "developer" roles help. - **No offboarding process.** Document and follow a checklist for removing access when someone leaves. - **No access reviews.** Set a quarterly calendar reminder to review active accounts. Export the user list, confirm each person still needs access, and document the review. --- ### How do I write an incident response plan for SOC 2? *Keywords: SOC 2 incident response plan, IRP template, security incident procedure* *Source: https://screenata.com/resources/answers/how-do-i-write-an-incident-response-plan-for-soc-2* ## What an Incident Response Plan Needs Your SOC 2 incident response plan (IRP) maps to CC7.3-CC7.5 in Trust Services Criteria. Auditors check that you have a documented process for handling security incidents, and that your team follows it. ## The Five Sections | Section | What to Include | |---------|----------------| | 1. Detection | How incidents are identified (monitoring tools, customer reports, automated alerts) | | 2. Classification | Severity levels and criteria (P1 = data breach, P2 = service outage, P3 = minor issue) | | 3. Response | Who gets notified, what actions they take, escalation path | | 4. Communication | How you notify affected customers, internal stakeholders, and regulators if required | | 5. Post-incident review | Root cause analysis process, timeline for review, lessons learned documentation | ## A Startup-Sized Example ### Detection "Security events are detected through Sentry error monitoring, AWS CloudWatch alarms, and PagerDuty alerting. Customers can report issues to security@company.com." ### Classification - **P1 (Critical):** Confirmed data breach, unauthorized access to customer data - **P2 (High):** Service outage affecting customers, credential compromise - **P3 (Medium):** Failed authentication attempts, minor configuration issues ### Response "P1: CTO notified within 15 minutes via PagerDuty. Affected systems isolated. Investigation begins immediately. P2: On-call engineer responds within 1 hour. P3: Tracked in Linear, addressed within 5 business days." ### Communication "Affected customers notified within 72 hours for P1 incidents. Status page updated for P2+ incidents." ### Post-Incident Review "Post-mortem document created within 5 business days. Team reviews root cause, timeline, and preventive measures. Document stored in Notion." ## Tips - **Keep it realistic.** If your team is five people, don't describe a Security Operations Center rotation. - **Name your tools.** PagerDuty, Sentry, Slack #incidents, auditors want specifics. - **Test it.** Run a tabletop exercise once before your audit so you can tell the auditor you've tested the plan. --- ### How do I write SOC 2 policies that pass an audit? *Keywords: SOC 2 policy writing, policies that pass audit, SOC 2 policy tips* *Source: https://screenata.com/resources/answers/how-do-i-write-soc-2-policies-that-pass-an-audit* ## What Makes a Policy Pass? A SOC 2 policy passes when the auditor can read it, look at your systems, and confirm the two match. That's it. The policy doesn't need to be long or complex, it needs to be *accurate*. ## Five Rules for Audit-Ready Policies ### 1. Name Your Actual Tools Bad: "The company uses encryption for data at rest." Good: "Customer data is stored in Supabase PostgreSQL with AES-256 encryption at rest enabled by default." ### 2. Assign Specific Roles Bad: "Management is responsible for security oversight." Good: "The CTO reviews access control settings quarterly. The engineering lead approves all production deployments." ### 3. Be Specific About Processes Bad: "Changes follow an approval workflow." Good: "All code changes require a GitHub pull request with at least one approving review before merge. Branch protection rules enforce this on the main branch." ### 4. Only Claim What You Actually Do This is the most important rule. If you write "quarterly access reviews" in your policy but you've never done one, the auditor will find that gap. It's better to set a realistic cadence and follow it. ### 5. Include Review Dates Every policy should state when it was last reviewed and by whom. Auditors check that policies are current. A policy last reviewed 18 months ago raises concerns. ## The Most Common Failure | Mistake | Why It Fails | Fix | |---------|-------------|-----| | Generic language | Auditor can't verify vague claims | Name specific systems | | Overpromising | Claiming controls you don't have | Write what's true | | Copy-paste templates | Policies don't match your setup | Customize for your stack | | Missing responsibilities | No one accountable | Assign names/roles | ## Where Screenata Helps Screenata writes policies by reading your codebase and cloud configuration. The output references your actual tools, roles, and workflows, so the policies match what the auditor will see during testing. No templates to customize, no gaps to fill. --- ### How do I write SOC 2 policies that reference my actual tech stack? *Keywords: SOC 2 policy tech stack, specific SOC 2 policies, codebase-aware policies* *Source: https://screenata.com/resources/answers/how-do-i-write-soc-2-policies-that-reference-my-actual-tech-stack* ## Why Tech-Specific Policies Matter Auditors test controls by comparing your policies against your actual systems. If your policy says "code changes are managed through a version control system," the auditor will ask *which one* and check its settings. Save everyone time by being specific upfront. ## Template Language vs. Tech-Specific Language | Policy Area | Generic Template | Tech-Specific Version | |-------------|-----------------|----------------------| | Version control | "A version control system is used" | "All source code is managed in GitHub with branch protection on main" | | Deployment | "Changes follow a controlled deployment process" | "Deployments are triggered by merging to main via Vercel's GitHub integration with preview deployments for all PRs" | | Authentication | "Multi-factor authentication is required" | "Employee access uses Google Workspace SSO with hardware key MFA. Application users authenticate via NextAuth with TOTP" | | Data storage | "Data is encrypted at rest" | "Customer data is stored in Supabase PostgreSQL with AES-256 encryption. File uploads use AWS S3 with SSE-S3 encryption" | | Monitoring | "Systems are monitored for anomalies" | "Application errors are tracked in Sentry. Infrastructure metrics are monitored via AWS CloudWatch with PagerDuty alerting" | ## How to Do It 1. **List your tools.** Write down every tool involved in: authentication, deployment, hosting, database, monitoring, alerting, communication, and access management. 2. **Map tools to controls.** For each SOC 2 control area, note which tools are involved. 3. **Write the policy statement.** Replace generic language with specific tool references. 4. **Verify accuracy.** Before the audit, confirm that your policy statements match current configurations. If you migrated from Heroku to Vercel last quarter, make sure the policy reflects that. ## Common Pitfall Don't include tools you've stopped using. Auditors will try to test controls against every system mentioned in your policies. If your policy references Datadog but you switched to Sentry six months ago, that creates unnecessary questions. ## Where Screenata Helps Screenata reads your codebase and cloud configs directly, generating policies that reference your actual tools. When your stack changes, Screenata detects the difference and flags policy updates needed. --- ### How does a US SaaS company add ISO 27001 to existing SOC 2? *Keywords: add ISO 27001 after SOC 2, US company ISO certification* *Source: https://screenata.com/resources/answers/how-does-a-us-saas-company-add-iso-27001-to-existing-soc-2* ## What You Already Have from SOC 2 | ISO 27001 Requirement | SOC 2 Source | Status | |----------------------|-------------|--------| | Access controls (A.9) | CC6.1-6.8 evidence | Done | | Change management (A.14) | CC8.1 evidence | Done | | Incident management (A.16) | CC7.3-7.5 evidence | Done | | Cryptographic controls (A.10) | CC6.7 evidence | Done | | Operations security (A.12) | CC7.1-7.2 evidence | Done | | Human resource security (A.7) | CC1.4 evidence | Done | | Supplier relationships (A.15) | CC9.1-9.2 evidence | Done | | Risk assessment (Clause 6.1) | CC3.1-3.4 risk assessment | Needs reformatting | ## What You Need to Create ### 1. ISMS Documentation (2-3 weeks) The Information Security Management System document formalizes your security program: - ISMS scope and boundaries - Information security objectives - Roles and responsibilities for ISMS governance - Process for continual improvement - Management commitment statement ### 2. Statement of Applicability (1 week) A document listing all 114 Annex A controls with: - Whether each control is applicable to your organization - Justification for including or excluding each control - Reference to your implementation evidence ### 3. Risk Assessment in ISO Format (1 week) Your SOC 2 risk assessment covers the content, but ISO 27001 expects: - Asset-based risk identification - Risk treatment plan - Residual risk acceptance by management - Risk register ### 4. Internal Audit (1-2 weeks) ISO 27001 requires an internal audit before certification: - Self-assessment against Annex A controls - Documentation of findings - Corrective action plans for any gaps ### 5. Management Review (1 day) Formal meeting with leadership covering: - ISMS performance - Internal audit results - Risk assessment updates - Improvement opportunities - Documented minutes ## Timeline | Phase | Duration | |-------|----------| | ISMS documentation | 2-3 weeks | | Statement of Applicability | 1 week | | Risk assessment reformatting | 1 week | | Internal audit | 1-2 weeks | | Management review | 1 day | | Certification body engagement | 1-2 weeks | | Stage 1 audit (documentation review) | 1-2 days | | Stage 2 audit (implementation review) | 2-3 days | | **Total** | **2-4 months** | ## Cost --- ### How does AI collect SOC 2 evidence from GitHub and AWS automatically? *Keywords: AI evidence collection, automated SOC 2 evidence, AI compliance automation* *Source: https://screenata.com/resources/answers/how-does-ai-collect-soc-2-evidence-from-github-and-aws-automatically* ## How Automated Evidence Collection Works AI compliance tools use the same APIs and interfaces that manual evidence collection uses, they just do it faster and more consistently. ### GitHub Evidence (Automated) | Evidence | Manual Process | Automated Process | |----------|---------------|-------------------| | Branch protection settings | Navigate to settings, screenshot | API call, screenshot capture | | Organization member list | Go to People page, screenshot | API export with role data | | PR review status | Open 25 individual PRs, screenshot each | API query, batch analysis | | 2FA enforcement | Navigate to security settings, screenshot | API check with screenshot | | Audit log export | Download CSV manually | API export for audit period | ### AWS Evidence (Automated) | Evidence | Manual Process | Automated Process | |----------|---------------|-------------------| | IAM user list with MFA status | Console → IAM → Users, screenshot | API call to list users, check MFA | | S3 public access settings | Console → S3 → each bucket, screenshot | API scan all buckets | | CloudTrail status | Console → CloudTrail, screenshot | API check trail configuration | | Security group rules | Console → VPC → each SG, screenshot | API export all security groups | | RDS encryption settings | Console → RDS → each instance, screenshot | API check each instance | ## What Makes AI Different from API Scripts Simple API scripts can pull data, but AI compliance tools go further: 1. **Interpret results.** The AI understands what the data means for SOC 2 compliance, not just what the data is. 2. **Map to controls.** Evidence is automatically tagged with the TSC criteria it satisfies. 3. **Identify gaps.** If a control is missing or misconfigured, the AI flags it. 4. **Generate screenshots.** For evidence that requires visual proof, the AI captures screenshots from admin interfaces. 5. **Organize for audit.** Evidence is arranged by control area, ready for auditor review. ## What Still Requires Manual Input Even with full automation, some evidence needs human involvement: - Risk assessment judgment calls - Vendor management evaluations - Security training completion confirmation - Incident response plan testing documentation - Physical security controls (if applicable) ## Where Screenata Fits Screenata automates evidence collection from GitHub, AWS, and your application interfaces. It captures both API data and application-level screenshots, maps everything to SOC 2 controls, and flags gaps, reducing evidence collection from 40+ hours to under 5. --- ### How does AI read my codebase to write compliance policies? *Keywords: AI codebase analysis, AI policy generation, automated compliance policies* *Source: https://screenata.com/resources/answers/how-does-ai-read-my-codebase-to-write-compliance-policies* ## How the AI Analysis Works ### Step 1: Connect (Read-Only Access) The AI tool connects to your GitHub repositories and cloud accounts with read-only permissions. It can see your code and configurations but can't modify anything. ### Step 2: Analyze Code Patterns The AI looks for specific patterns that map to SOC 2 controls: | What It Finds | SOC 2 Mapping | Policy Output | |---------------|---------------|---------------| | NextAuth or Clerk configuration | CC6.1 (Access Controls) | "Users authenticate via [provider] with [MFA method]" | | GitHub Actions workflow files | CC8.1 (Change Management) | "CI runs [test suite] on every PR before merge" | | AWS IAM policies | CC6.1 (Logical Access) | "Cloud access restricted via IAM roles with [specific policies]" | | Database encryption settings | CC6.7 (Data Protection) | "Data at rest encrypted using [method] on [provider]" | | Sentry/DataDog configuration | CC7.2 (Monitoring) | "Application errors tracked via [tool] with [alerting rules]" | ### Step 3: Map to Controls The AI maps discovered patterns to Trust Services Criteria, identifying which controls your systems already satisfy and which have gaps. ### Step 4: Generate Policies For each control area, the AI writes policy statements that reference your actual systems. Instead of "the company uses encryption," it writes "customer data at rest is encrypted using AES-256 in Supabase PostgreSQL." ### Step 5: Identify Gaps The AI flags areas where it can't find controls, missing MFA enforcement, no branch protection, no logging configuration. These become your remediation priorities. ## What the AI Doesn't Do - Doesn't read your proprietary business logic or trade secrets (focuses on infrastructure and security patterns) - Doesn't modify your code - Doesn't store your source code - Doesn't replace the auditor ## Privacy Consideration Codebase-aware tools typically analyze patterns and configurations, not business logic. They look at *how* you authenticate users, not *what* your application does with their data. Check each tool's data handling policy before connecting your repos. --- ### How does Screenata write SOC 2 policies from my codebase? *Keywords: AI policy writing, Screenata policies, codebase-aware compliance* *Source: https://screenata.com/resources/answers/how-does-screenata-write-soc-2-policies-from-my-codebase* ## How Does Codebase-Aware Policy Generation Work? Traditional SOC 2 policies are written from templates. A consultant interviews your team, learns about your systems, then customizes generic documents. The result often has gaps because consultants learn through conversation, they can miss implementation details, edge cases, or recent changes. Screenata takes a different approach. It reads your source code and cloud configuration directly, building a technical understanding of how your systems actually work. Then it writes policies that reference those specific systems. ## What Screenata Analyzes | System Area | What It Reads | Policy It Generates | |-------------|---------------|-------------------| | Authentication | NextAuth, Auth0, Clerk configs | Access control policy with your actual auth provider | | Deployment | Vercel, AWS, GitHub Actions configs | Change management policy with your CI/CD pipeline | | Data storage | Database schemas, encryption settings | Data protection policy with your actual storage setup | | Access controls | IAM policies, RBAC implementations | Logical access policy with your permission model | | Monitoring | Logging configs, alerting rules | Incident response plan with your actual tools | ## Why This Matters for Audits SOC 2 auditors test whether your controls operate as your policies describe. If your policy says "all code changes require pull request approval" but your GitHub repo allows direct pushes to main, that's a finding. When policies are generated from your actual codebase, they describe what you actually do, not what a template assumed you do. ## The Process 1. **Connect:** Grant Screenata read access to your GitHub repos and cloud accounts. 2. **Analyze:** Screenata scans your authentication, deployment, access control, and data handling code. 3. **Generate:** Policies are written referencing your specific tools, configurations, and workflows. 4. **Review:** You review each policy, make adjustments, and approve. 5. **Evidence:** Screenata maps each policy statement to the evidence it can collect automatically. --- ### How fast can I get SOC 2 Type I certified? *Keywords: fast SOC 2, SOC 2 Type 1 timeline, quick SOC 2 certification* *Source: https://screenata.com/resources/answers/how-fast-can-i-get-soc-2-type-i-certified* ## What Is the Fastest Realistic Timeline? Four to six weeks from start to report. This assumes you are a cloud-native startup with MFA already enabled, code reviews in place, and no major security gaps. The constraint is not preparation, it is auditor scheduling and fieldwork. ## The Speed Run Breakdown | Week | Activities | |------|-----------| | Week 1 | Run readiness assessment, enable missing security defaults (MFA, encryption, logging) | | Week 2 | Write policies, set up access reviews, document your system boundary | | Week 3 | Collect all evidence, organize by control area, submit to auditor | | Week 4 | Auditor walkthrough meetings and evidence review | | Week 5 | Auditor completes testing, remediate any findings | | Week 6 | Report drafted and delivered | ## Prerequisites for a Fast Type I You need these in place before starting: - Cloud infrastructure (AWS, GCP, or Azure) with encryption enabled - GitHub or GitLab with branch protection and PR reviews - MFA on all business accounts - An identity provider (Google Workspace, Okta, or similar) - Fewer than 50 employees (smaller teams = smaller scope) If you are missing any of these, add 1–2 weeks for implementation. ## What Cannot Be Compressed - **Auditor scheduling**, Most firms need 2–4 weeks lead time - **Fieldwork**, Auditors need 2–3 weeks minimum to review evidence and conduct walkthroughs - **Report writing**, The auditor's internal review process takes 1–2 weeks ## What Can Be Compressed - **Policy writing**, AI tools generate policies in hours instead of weeks - **Evidence collection**, Automated tools capture screenshots and configs in a day - **Gap remediation**, Cloud-native fixes (enable MFA, configure logging) take hours, not weeks Screenata compresses the preparation phase to days. Connect your GitHub and cloud accounts, and it generates policies and collects evidence automatically, so you are ready for auditor fieldwork in under two weeks. --- ### How long does it take to get SOC 2 certified? *Keywords: SOC 2 timeline, how long SOC 2, SOC 2 duration* *Source: https://screenata.com/resources/answers/how-long-does-it-take-to-get-soc-2-certified* ## How Long Does SOC 2 Take? The total timeline depends on your starting point and which type of report you need. A cloud-native startup with basic security practices can get a Type I report in 6–8 weeks. A company starting from scratch needs 10–16 weeks. ## Timeline Breakdown | Phase | Type I | Type II | |-------|--------|---------| | Gap assessment | 1–2 weeks | 1–2 weeks | | Policy writing | 1–3 weeks | 1–3 weeks | | Control implementation | 1–4 weeks | 1–4 weeks | | Evidence collection | 1–2 weeks | Continuous (3–12 months) | | Auditor fieldwork | 2–4 weeks | 3–6 weeks | | Report delivery | 1–2 weeks | 1–2 weeks | | **Total** | **6–16 weeks** | **6–18 months** | ## What Slows Things Down The most common delays: 1. **Policy writing**, Startups without compliance experience spend weeks writing policies from scratch 2. **Missing controls**, Implementing MFA, access reviews, or logging from scratch adds time 3. **Auditor availability**, Popular audit firms book 4–8 weeks out 4. **Evidence gaps**, Discovering during fieldwork that evidence is missing or insufficient 5. **Scope creep**, Adding Trust Services Criteria or systems mid-process ## What Speeds Things Up - Start with Security-only scope - Use AI tools to generate policies from your actual infrastructure - Choose a startup-friendly auditor who moves quickly - Collect evidence as you implement controls, not after - Keep your system boundary small and focused ## The Fastest Path For maximum speed: use Screenata to generate policies and collect evidence (days, not weeks), scope to Security only, choose a small audit firm, and target a Type I first. Some startups get from kickoff to report in under 6 weeks. --- ### How many screenshots do auditors actually need for SOC 2? *Keywords: SOC 2 sample size, audit sampling, how many screenshots SOC 2* *Source: https://screenata.com/resources/answers/how-many-screenshots-do-auditors-actually-need-for-soc-2* ## Evidence Volume by Audit Type | Audit Type | Configuration Evidence | Population Samples | Total Pieces | |------------|----------------------|-------------------|-------------| | Type I | 40-60 screenshots | None | 40-60 | | Type II (3-month window) | 40-60 screenshots | 10-15 per control tested | 80-120 | | Type II (12-month window) | 40-60 screenshots | 20-25 per control tested | 120-200 | ## How Auditors Determine Sample Size Auditors follow AICPA sampling guidance. For population-based testing, the sample size depends on how many times the control operated during the audit period: | Population Size | Typical Sample | |----------------|---------------| | 1-5 events | Test all | | 6-50 events | 5-10 samples | | 51-250 events | 15-20 samples | | 250+ events | 25 samples | For example, if you merged 300 PRs during a 12-month audit period, the auditor samples 25 PRs to verify change management controls. ## What Gets Screenshotted Most | Control Area | Screenshots Needed | |-------------|-------------------| | Access controls (CC6) | MFA settings, user lists, role assignments, access reviews, 10-15 screenshots | | Change management (CC8) | Branch protection, CI config, sample PRs, 5-10 screenshots + population | | System monitoring (CC7) | Alerting config, logging settings, incident records, 5-10 screenshots | | Logical access (CC6) | Firewall rules, security groups, encryption, 5-10 screenshots | | Risk management (CC3) | Risk assessment document, vendor reviews, 3-5 documents | ## How to Reduce the Burden - **Automate infrastructure evidence** with GRC platforms or API integrations - **Use Screenata** for application-level screenshots with built-in timestamps - **Maintain controls consistently**, auditors request more samples when they find exceptions - **Organize by control**, create folders matching TSC criteria (CC6.1, CC7.2, CC8.1) so evidence is easy to find during the audit --- ### How much does a HIPAA audit cost? *Keywords: HIPAA audit cost, HIPAA risk assessment cost, HIPAA attestation price, HIPAA compliance cost small business* *Source: https://screenata.com/resources/answers/how-much-does-a-hipaa-audit-cost* ## How much does a HIPAA audit cost? ### The three things "HIPAA audit" can mean When a customer asks for proof of your HIPAA compliance, they usually mean the second row. When your own team says "we should get a HIPAA audit," they usually mean the first. ## What drives the price Scope. An assessor prices the engagement on the number of systems that store or transmit PHI, the number of PHI flows between them and to vendors, workforce size, and physical locations. A ten-person telehealth startup with one cloud environment sits at the bottom of the ranges above. A multi-site provider group with an EHR, imaging systems, and dozens of business associates sits well past the top of them. The quoted fee is also not the whole cost. An assessment produces findings, and remediating them, tightening access, adding logging, signing missing BAAs, writing the policies that do not exist yet, is engineering and administrative time the assessor's invoice never shows. ## There is no official certification to buy This is the fact that reframes the budget question. HHS certifies nothing and endorses no assessor, so no amount of spending produces a government-recognized HIPAA credential. A third-party attestation is still worth paying for, because customers accept it as evidence, but it is evidence of a private examination, and any vendor selling a "HIPAA certification" is selling exactly that. What the law actually requires is the underlying work: a documented risk analysis, safeguards that operate, and BAAs with every vendor that touches PHI. ## Where Screenata fits --- ### How much does HIPAA certification cost? *Keywords: HIPAA certification cost, how much does it cost to get HIPAA certified, HIPAA compliance cost, HITRUST cost* *Source: https://screenata.com/resources/answers/how-much-does-hipaa-certification-cost* ## How much does HIPAA certification cost? ### What you can actually buy ## Why the question keeps getting asked Because vendors sell "HIPAA certified" badges, and because enterprise procurement asks for one. Both sides of that exchange are working from a premise the regulation does not support. HHS is explicit that it does not endorse or certify, and the enforcement mechanism is investigation after a complaint or breach, not a certificate you renew. The practical consequence: a HIPAA certificate from a vendor carries whatever weight the buyer assigns to that vendor's name, which is usually little. ## What buyers accept instead In practice, a healthcare buyer asking for HIPAA assurance will accept: 1. **A signed BAA.** Non-negotiable, and it is a contract rather than a certificate. 2. **A SOC 2 Type II report**, often with HIPAA criteria mapped into the scope. This is the common answer because it carries an independent CPA firm's opinion. 3. **Your risk analysis and safeguard documentation**, if they are technical enough to read it. HITRUST appears when the buyer is a large health system or payer that mandates it. It is expensive and slow, and worth it only when a named customer requires it. ## The real cost of HIPAA compliance The assessment is rarely the largest line. The work is: - **Risk analysis.** Required by the Security Rule, and the single most common enforcement finding when it is missing. - **Remediation.** Encryption, access control, audit logging, whatever the analysis surfaces. - **Policies and training.** Written, distributed, and recorded per person. - **BAAs.** With every vendor touching PHI, and their subcontractors under the Omnibus Rule. - **Ongoing evidence.** Access reviews, log review, incident records. --- ### How much does HIPAA compliant Gmail cost? *Keywords: HIPAA compliant Gmail cost, Google Workspace BAA, is Gmail HIPAA compliant, HIPAA compliant email pricing* *Source: https://screenata.com/resources/answers/how-much-does-hipaa-compliant-gmail-cost* ## How much does HIPAA compliant Gmail cost? One wording note: Google's own term is "HIPAA-eligible," not "HIPAA compliant," and the distinction is real. Workspace gives you an email service that can be used in a compliant way. Whether your organization is compliant depends on configuration and process, covered below. ### What each option costs and what the BAA covers ## The BAA is free, and it is not the whole job The BAA obligates Google to safeguard PHI in the covered services and report breaches on its side. It does not configure your account, and it does not govern your staff. To use Gmail with PHI defensibly you still need to do your part of the Security Rule: - **Access controls.** Unique accounts per user, 2-step verification enforced, and prompt offboarding when someone leaves. - **Transmission security.** Gmail encrypts mail in transit by default, but mail to a recipient whose server does not support TLS can fall back; sensitive workflows often add a secure-messaging layer or use Workspace rules to restrict where PHI can be sent. - **Retention and auditability.** Admin audit logs, and on Business Plus, Vault retention rules that match your record-keeping obligations. - **Organizational measures.** A documented risk assessment, written policies, and workforce training. A signed BAA with an untrained team is how most email-related violations happen. ## The rest of your stack needs BAAs too Email is rarely the only place PHI lives. Every vendor that stores or transmits PHI for you, EHR, scheduling, analytics, transcription, needs its own BAA. Our [BAA directory](/hipaa) tracks which common software vendors will sign one and on which plans, which makes it a quick check before PHI reaches a new tool. --- ### How much does ISO 27001 cost? *Keywords: ISO 27001 cost, ISO 27001 certification cost, ISO certification price, ISO 27001 audit fees* *Source: https://screenata.com/resources/answers/how-much-does-iso-27001-cost* ## How much does ISO 27001 cost? ### Where the money goes ## The three-year cycle is the real budget ISO 27001 is not a one-time purchase. The certificate runs on a **three-year cycle**: certification audit in year one, surveillance audits in years two and three, then recertification. Budgeting only for year one understates the commitment by roughly half. ## Two rules that affect the price **Your certification body must be independent of your implementer.** A firm that helped you build the ISMS cannot certify it. This is unlike the US consulting market and it catches people out when they discover the friendly consultant cannot sign the certificate. **Scope drives cost more than anything else.** The audit is priced on the scope statement: which entities, which locations, which systems. A scope covering one product and one office costs materially less than one covering the whole company. Narrow scope honestly, then widen it later. ## What makes ISO 27001 cost more than SOC 2 to implement The audit fees are broadly comparable. The implementation is not, because ISO requires a **management system** that SOC 2 has no equivalent for: - A defined scope and information security policy - A documented risk assessment methodology, applied - A **Statement of Applicability** covering all 93 Annex A controls, each included or excluded with justification - Internal audit, performed by someone independent of the work - Management review at planned intervals Those five are the deliverables that consume the time. ## Where a platform changes the number That covers the implementation and evidence side. **The certification body fee is separate and paid to them, not to us**, and we do not sell audits or take referral fees from auditors, so the firm you choose is your decision. --- ### How should a 10-person startup prepare for SOC 2? *Keywords: small startup SOC 2, early-stage SOC 2, SOC 2 small team* *Source: https://screenata.com/resources/answers/how-should-a-10-person-startup-prepare-for-soc-2* ## Your Size Is an Advantage A 10-person startup has fewer systems, fewer users, and simpler processes than a 500-person company. That means fewer controls to implement, less evidence to collect, and a smaller audit scope. Don't let the process intimidate you. ## The SOC 2 Prep Checklist for Small Teams ### Week 1-2: Security Foundations | Task | Time | Why | |------|------|-----| | Enforce MFA on all systems | 2 hours | Required for CC6.1, easy win | | Enable GitHub branch protection | 30 minutes | Required for CC8.1 | | Set up an MDM (Kandji, Mosyle) | 2-3 hours | Endpoint security evidence | | Enable CloudTrail (if using AWS) | 30 minutes | Audit logging evidence | ### Week 3-4: Policies Write seven core documents describing what you *actually do*: 1. Information Security Policy 2. Access Control Policy 3. Change Management Policy 4. Incident Response Plan 5. Risk Assessment 6. Vendor Management Policy 7. System Description ### Week 5-6: Evidence Collection Start collecting evidence for each control area. Screenshot configurations, export user lists, document your quarterly access review. ### Week 7-8: Readiness Assessment Review everything against Trust Services Criteria. Identify gaps and fix them before engaging an auditor. ## What 10-Person Startups Usually Have Already - GitHub with PRs (change management ✓) - Google Workspace with MFA (access controls ✓) - Cloud provider with encryption defaults (data protection ✓) - Slack for communication (incident response channel ✓) ## What You Probably Need to Add - MDM for company devices - Formal access review process (quarterly) - Security awareness training - Background checks for new hires - A written incident response plan ## Where Screenata Helps --- ### How should an MSP manage compliance evidence for multiple clients? *Keywords: MSP compliance, multi-client SOC 2, managed compliance* *Source: https://screenata.com/resources/answers/how-should-an-msp-manage-compliance-evidence-for-multiple-clients* ## The MSP Compliance Challenge Managed Service Providers handle compliance evidence for multiple clients simultaneously. Each client may need SOC 2, HIPAA, or ISO 27001, and each auditor has different expectations. Without standardization, evidence collection becomes unsustainable. ## The Standardized Approach ### Step 1: Create a Master Control Framework Define your standard controls that apply to all clients: | Control Area | MSP Standard | Applied To | |-------------|-------------|------------| | Access management | SSO + MFA for all client environments | All clients | | Change management | PR-based workflow with reviews | All clients | | Monitoring | Centralized logging and alerting | All clients | | Incident response | Shared IRP with client-specific escalation | All clients | | Backup | Automated backups with defined retention | All clients | ### Step 2: Client-Specific Documentation For each client, maintain: - Client-specific system description - Client data handling documentation - Client-specific access lists - Client environment configuration evidence ### Step 3: Shared vs. Client-Specific Evidence | Evidence Type | Shared Across Clients | Client-Specific | |---------------|----------------------|-----------------| | Your internal policies | Yes | No | | Your access review process | Yes | No | | Client environment configs | No | Yes | | Client data flow diagrams | No | Yes | | Your training records | Yes | No | | Client access provisioning | No | Yes | ## Scaling Evidence Collection ### Under 5 Clients Manual collection with standardized templates. One compliance coordinator can handle this. ### 5-20 Clients Automated infrastructure monitoring per client environment. Standardized evidence collection scripts. Dedicated compliance person. ### 20+ Clients Full automation required. Invest in: - Multi-tenant compliance dashboard - Automated evidence collection across all client environments - Template-based reporting for each framework - Client-facing compliance portals ## Tips for MSPs - **Start with your own SOC 2.** Before managing client compliance, get your own house in order. - **Standardize client onboarding.** Every new client gets the same security controls from day one. - **Automate everything possible.** Evidence collection that takes 30 minutes per client times 20 clients is 10 hours of recurring work. - **Use Screenata** to automate application-level evidence collection across client environments, reducing per-client effort significantly. If you run compliance delivery across a client book, [Screenata for vCISOs and MSPs](/for-vcisos) covers the firm-admin account spanning client tenants and the partner economics. --- ### How do you know if software is HIPAA compliant? *Keywords: how to know if software is HIPAA compliant, HIPAA compliant software checklist, BAA software vendors, HIPAA technical safeguards software* *Source: https://screenata.com/resources/answers/how-to-know-if-software-is-hipaa-compliant* ## How do you know if software is HIPAA compliant? You cannot, because no software is HIPAA compliant on its own. HIPAA regulates organizations, covered entities and their business associates, and compliance attaches to how a tool is used, not to the tool. The practical test is 4 checks: the vendor signs a BAA, the product supports the required technical safeguards, the vendor has independent security attestations as supporting evidence, and the software is configured and used correctly on your side. Fail any one and PHI in that software is a problem, whatever the marketing page says. ### The 4 checks and what to ask for | # | Check | What to ask the vendor for | |---|---|---| | 1 | Will they sign a BAA? | A signed Business Associate Agreement before any PHI enters the system. A refusal is disqualifying by itself; note that some vendors sign only on higher-priced plans | | 2 | Does it support the technical safeguards? | Encryption in transit and at rest, role-based access controls, unique user accounts, audit logs of who accessed what, and automatic logoff or session timeout | | 3 | Is there independent evidence of their security? | A SOC 2 Type II report (under NDA), an ISO 27001 certificate, or a HITRUST assessment. Supporting evidence only; none of these equals HIPAA compliance | | 4 | Is it configured and used correctly by you? | Their admin or implementation guide for HIPAA settings; then do your part: restrict access, enable logging, train staff, include the tool in your risk assessment | ## "HIPAA certified" badges are marketing There is no official HIPAA certification. HHS does not certify software and does not accredit anyone else to. When a product page says "HIPAA certified," it means the vendor paid for a private assessment, or in the worst case, that someone made a badge. Private assessments can be genuinely useful evidence, but the badge alone tells you nothing you can rely on. The checks above are what the badge is trying to shortcut. ## Where the checks come from Checks 1 and 2 map directly to the law. The BAA requirement comes from the Privacy Rule: any vendor that creates, receives, or transmits PHI on your behalf is a business associate and must be under a BAA. The technical safeguards in check 2 come from the Security Rule, which names access control, audit controls, integrity, authentication, and transmission security as the categories a covered system has to address. Check 3 is not in the law at all, which is exactly why it matters to say so. A SOC 2 report tells you the vendor's security controls were examined by an independent auditor, which is the best generally available signal that checks 1 and 2 are more than promises. Treat it as evidence about the vendor, never as proof of your own compliance. Check 4 is where most real-world failures happen. A compliant-capable product with shared logins, logging disabled, and no offboarding process puts you in violation with every safeguard technically available and none of them operating. ## Where Screenata fits If you are the software vendor on the receiving end of these questions, Screenata's HIPAA and SOC 2 programs produce the artifacts buyers ask for in checks 1 through 3: a documented risk assessment, policies generated from scans of your actual infrastructure, and cryptographically signed evidence packs, with about 70% of evidence collected automatically. Which vendors sign BAAs, and on which plans, is tracked in our [BAA directory](/hipaa). --- ### What is SOC 2 certification? *Keywords: SOC 2 certification, soc2 certification, SOC 2 certified, is SOC 2 a certification* *Source: https://screenata.com/resources/answers/is-soc-2-a-certification* ## What is SOC 2 certification? **There is no SOC 2 certification.** SOC 2 produces an **attestation report**: a licensed CPA firm examines your controls against the AICPA Trust Services Criteria and issues a report containing its opinion. There is no certificate, no certifying body, and no badge. The term "SOC 2 certified" is used constantly and it is not accurate, which matters more than it sounds. ### Certification and attestation are different things | | Certification (ISO 27001) | Attestation (SOC 2) | |---|---|---| | Issued by | An accredited certification body | A licensed CPA firm | | Output | A certificate | A report with an opinion | | Shared how | Displayed publicly | Under NDA, on request | | Time model | Valid for three years with surveillance | Covers a defined period | | Verified by | Accreditation bodies | AICPA peer review | ## Why the distinction has practical consequences **You cannot display it.** There is no badge to put in your footer that means anything. What you have is a document, usually shared under NDA during a security review. Vendors selling "SOC 2 certified" seals are selling something the framework does not produce. **It covers a period, not a date.** A Type II report covers an observation window. When that window ends, coverage does not extend to today, which is why [bridge letters](/resources/answers/what-is-a-soc-2-bridge-letter-and-when-do-you-need-one) exist. **Only a CPA firm can issue it.** Platforms and consultants prepare you. They cannot sign the opinion, and independence rules prevent whoever produced the evidence from attesting to it. Any vendor implying otherwise is describing something that would not be a SOC 2 report. ## Type I and Type II - **Type I** tests whether controls are suitably designed at a point in time. Faster and cheaper, and commonly accepted while you work toward Type II. - **Type II** tests whether they **operated effectively throughout a period**, typically three to twelve months. This is what most enterprise buyers eventually want, because it tests operation rather than intent. ## What buyers actually ask for In practice a security review asks for the report itself, and increasingly for a current one. Saying "we are SOC 2 certified" to a procurement team that knows the difference reads as unfamiliarity with your own compliance posture. Saying "we have a SOC 2 Type II report covering January to December, and I can share it under NDA" reads as competence. ## What it costs --- ### Is SOC 2 legally required? *Keywords: is SOC 2 legally required, is SOC 2 mandatory, SOC 2 law, SOC 2 compliance requirement* *Source: https://screenata.com/resources/answers/is-soc-2-legally-required* ## Is SOC 2 legally required? No. SOC 2 is not required by any law, regulation, or government agency. It is a voluntary attestation standard created by the AICPA (the American Institute of Certified Public Accountants), a private professional body, and no statute in the US or anywhere else references it as an obligation. Nobody gets fined for not having SOC 2. The pressure to get one comes entirely from customers, who write it into procurement requirements and vendor security reviews. ## What SOC 2 actually is A SOC 2 report is an independent CPA firm's attestation that your controls meet the AICPA Trust Services Criteria. It comes in two forms: Type I examines control design at a point in time, and Type II examines whether controls operated over a period, usually 3 to 12 months. It is an audit opinion, not a certification and not a license. There is no government registry of SOC 2 holders and no regulator that checks whether you have one. ## SOC 2 versus regimes that are actually law The confusion usually comes from lumping SOC 2 in with legal regimes it gets compared to. The table separates them. | Regime | Legally required? | Who enforces it | Who it applies to | |---|---|---|---| | SOC 2 | No, voluntary attestation | Customers, via contracts and procurement | Any service organization whose customers ask | | HIPAA | Yes, US federal law | HHS Office for Civil Rights | Healthcare providers, plans, and their business associates | | GDPR | Yes, EU regulation | EU data protection authorities | Anyone processing EU residents' personal data | | NYDFS 23 NYCRR 500 | Yes, state regulation | New York Department of Financial Services | NY-licensed banks, insurers, and financial firms | | PCI DSS | No statute, but contractually required | Card networks and acquiring banks | Anyone handling card payments | Two things follow from this. First, if you are subject to HIPAA or GDPR, a SOC 2 report does not discharge those obligations; the laws impose their own requirements directly. Second, PCI DSS is the closest analogue to SOC 2: both are private-sector requirements enforced through contracts, and both are unavoidable in practice for the companies they touch. ## Why it feels mandatory anyway For B2B software companies, SOC 2 operates as a de facto requirement because it is the standard artifact security teams ask for. A typical enterprise security review asks for a SOC 2 Type II report before anything else, and "we do not have one" commonly stalls or kills the deal, or gets you routed into a longer questionnaire process instead. The requirement is real; its source is the contract in front of you rather than a statute. That distinction matters for timing. A legal requirement applies from day one. A commercial requirement applies when your pipeline says so, which means an early-stage company selling to startups can reasonably defer SOC 2, and a company entering mid-market sales cycles usually cannot. Most teams start the process when the first serious deal asks for it, and a Type II report takes an observation window of 3 to 12 months plus audit time, so starting after the deal arrives means months of delay. ## What it costs to close the gap ## The short version No law requires SOC 2. Your next enterprise contract probably will. --- ### Is Workstreet worth it for SOC 2 preparation? *Keywords: is Workstreet worth it, Workstreet review, Workstreet pricing, Workstreet SOC 2, Workstreet vCISO cost, Workstreet alternative, Vanta service partner, vCISO for SOC 2* *Source: https://screenata.com/resources/answers/is-workstreet-worth-it-for-soc-2-preparation* ## Is Workstreet worth it for SOC 2 preparation? It depends on whether you are buying expertise or buying execution. Workstreet is a managed security and compliance services firm, not a compliance platform. It sells virtual CISO services, SOC 2 and ISO 27001 preparation, security questionnaire handling, penetration testing, and Vanta implementation. It calls itself Vanta's number one services partner with Platinum status, and claims 2,200+ customers, with Clay, Cursor, Granola, and Black Forest Labs on its logo wall. That is a real firm with real references. The question is whether the work you need is the work that requires humans. ## What it costs Workstreet publishes no package rate card. Its own blog on vCISO pricing states the numbers: Two costs sit underneath that and are easy to forget when comparing quotes. So a Workstreet-led first SOC 2 is realistically the services retainer plus platform plus auditor. On the low end that is meaningfully more than the platform-plus-consultant path costs on average, and on the high end it is a different budget category entirely. ## When Workstreet is the right call Buy the human layer when the judgment is the hard part: 1. Complex or regulated scope: HIPAA overlap, healthcare or financial data, multi-product or multi-entity boundaries. 2. No technical bandwidth at all, where nobody internally can answer an auditor's question about your own infrastructure. 3. You want an accountable long-term security partner, not just a report, including questionnaire handling and ongoing vCISO coverage. 4. You are already deep in Vanta and want the fastest path from a stalled implementation to a finished audit. That last case is common enough to name. Buying a GRC platform and stalling three to six months in is the single most predictable failure in this market, and paying a services firm to unstick it is a rational purchase. ## When it is more than you need For a standard first SOC 2, most of the preparation work is repeatable and template-driven: scoping, policy generation, the risk assessment, the system description, the control matrix, evidence collection. You are paying senior consulting rates for output that follows a known shape. The profile where that is true: single product, B2B SaaS, AWS or GCP, under 50 employees, Security TSC only, Type I first. If that describes you, an AI agent produces the same deliverables from your actual infrastructure configuration. One 17-year audit veteran put the underlying point bluntly to us: "Many vCISOs are using an LLM and a control template they've pulled from a GRC tool. You can do that yourself." That is not true of every firm, and it is not a claim about Workstreet specifically. It is the reason to check what you are buying before you sign a retainer. ## Cost comparison for a first Type I The auditor line is identical in every row. Screenata does not bundle the audit and does not take referral fees from audit firms, so the firm you choose is your decision. Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## How to decide Ask a services firm these before signing: 1. What is the fixed fee for a Security-only Type I, and what is explicitly out of scope? 2. Which parts of the work are template-driven, and which genuinely require your judgment? 3. Does the retainer continue after the report is issued, and can I stop it? 4. Is the GRC platform license included or billed separately? 5. Who signs the audit, and are they independent of you? If the answers come back mostly template-driven with a long retainer, price an agent against it. If your scope is genuinely complex, pay for the humans and do not feel bad about it. --- ### What are ISO 27001 certification companies? *Keywords: ISO 27001 certification companies, iso certification companies, ISO 27001 certified company, ISO 27001 certification body, ISO 27001 certification consultants* *Source: https://screenata.com/resources/answers/iso-27001-certification-companies* ## What are ISO 27001 certification companies? ISO 27001 certificates are issued by **accredited certification bodies**, not by consultants, auditors of other kinds, or software vendors. The body must be accredited by a recognised national accreditation body such as **UKAS** in the UK or **ANAB** in the US, and it must be **independent of whoever helped you implement** the management system. That independence rule catches most first-time buyers out. ### Three different suppliers, and people conflate them | Supplier | Does | Cannot do | |---|---|---| | **Certification body** | Runs Stage 1 and Stage 2 audits, issues the certificate | Consult on building your ISMS | | **Consultant** | Helps build the ISMS, writes the Statement of Applicability, runs gap analysis | Issue a certificate | | **Compliance platform** | Manages controls, evidence, and the crosswalk to other frameworks | Issue a certificate | The rule comes from **ISO/IEC 17021**, the impartiality standard for certification bodies. A body that designed your management system cannot then certify it. This differs from the US consulting norm, which is why teams coming from a SOC 2 background are frequently surprised. ## Accredited versus unaccredited Unaccredited certificates exist, cost less, and are worth correspondingly less. An enterprise buyer with a mature vendor-risk process will check the accreditation, and a certificate from a body with no recognised accreditation fails that check. **How to verify:** look the body up on its accreditation body's public register (UKAS, ANAB, or your national equivalent) and confirm the scope covers ISO/IEC 27001. An accreditation logo on a marketing page is not evidence. ## What the audit actually involves 1. **Stage 1.** Documentation review. Is the ISMS defined, is the scope coherent, does the Statement of Applicability justify inclusions and exclusions across all 93 Annex A controls? 2. **Stage 2.** Implementation audit. Is it actually operating, with evidence? 3. **Surveillance,** years two and three, roughly a third of the initial fee each. 4. **Recertification** in year three, restarting the cycle. ## Choosing between them Price varies more than quality at the accredited tier, and the variables that move it are headcount, number of sites, and scope. Ask each body for a quote against the same scope statement, and ask how many auditors they have with experience in your sector, because that determines how much explaining you do during Stage 2. See [how much does ISO 27001 cost](/resources/answers/how-much-does-iso-27001-cost) for the full cost breakdown including the three-year cycle. ## Where a platform fits --- ### Should I budget the SOC 2 audit and remediation separately? *Keywords: SOC 2 remediation cost, SOC 2 budget, SOC 2 audit vs remediation, how to budget for SOC 2, SOC 2 hidden costs, SOC 2 implementation cost* *Source: https://screenata.com/resources/answers/should-i-budget-the-soc-2-audit-and-remediation-separately* ## Why Separate the Audit From Remediation? Remediation is the work the auditor tests. It covers every control in scope: MFA on admin accounts, branch protection and reviewed changes, encryption at rest, log retention, an incident response plan you have exercised, a backup restore you have actually run, offboarding inside the window your policy promises, and a review of the vendors that touch customer data. Its cost depends on the gap between your current setup and those controls, and it is paid mostly in your team's hours. A single budget line for "SOC 2" hides the part that varies inside the part that doesn't. ## What Does Each Line Cost? The audit row is identical across the table. Everything that separates the paths is in the rows below it. Model your own report type and plan with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator), and see how the platform lines compare vendor by vendor in [the real cost of SOC 2](/resources/blog/the-real-cost-of-soc-2-why-the-cheapest-platform-isnt-the-cheapest-program). ## What Happens When Both Are One Budget? The usual failure is a report bought against the audit budget alone. The fee is small, so the choice optimizes for the fee, and the remediation gets squeezed into whatever time is left before fieldwork. The report can still come back looking complete. The cost shows up later, inside a customer's procurement. An enterprise buyer's security team reads the report line by line, finds a control that was covered lightly, and asks for evidence that it works. Now the control has to be fixed and tested again while the deal waits, which is the most expensive moment to do work that was always going to be needed. If you are weighing a vendor that sells the audit inside its price, ask one question before you sign: does your platform vendor also provide your auditor? ## How Do You Keep Remediation From Growing? 1. **Scan before you scope.** Find the gaps against your actual cloud, code, and identity setup before you book an auditor, so the remediation budget is based on what you found rather than a guess. 2. **Scope to Security only** unless a customer contract requires Availability, Confidentiality, or Privacy. 3. **Count a control as done only when there is dated evidence that it works.** A setting that is on but undocumented gets requested again during fieldwork. 4. **Re-check on a schedule.** Settings drift during a Type II window, and a drifted control found by the auditor costs more than one found by you. 5. **Choose the auditor yourself**, and confirm its AICPA peer review is published. See [which SOC 2 auditor a startup should choose](/resources/answers/which-soc-2-auditor-should-a-startup-choose). ## Where Does Screenata Fit? Screenata cuts the remediation line rather than the audit line. Vera scans your cloud, code, and identity providers, writes the fix steps for each failing check, opens the ticket, and re-verifies after your engineer applies the change; the finding closes on its own once the nightly re-check passes. Evidence comes in through APIs, screenshots, and guided procedures, dated and signed so any auditor can verify it. Your team's part in a Type II year is 60–80 hours of applying fixes, approvals, and attestations. --- ### Should I start with SOC 2 Type I or go straight to Type II? *Keywords: SOC 2 Type 1 or Type 2, which SOC 2 first, SOC 2 start* *Source: https://screenata.com/resources/answers/should-i-start-with-soc-2-type-i-or-go-straight-to-type-ii* ## Type I or Type II First? Start with Type I unless you have a specific reason to skip it. Type I gets you a report in 4–8 weeks. Type II requires a 3–12 month observation period before you even begin the audit. If a prospect is waiting on your SOC 2 report, Type I unblocks the deal now. ## Decision Framework | Your Situation | Recommendation | Why | |---------------|---------------|-----| | Active deal blocked on SOC 2 | Type I first | Gets a report in weeks | | No urgent deals, controls already mature | Go straight to Type II | Avoid paying for two audits | | First-time compliance, unsure of readiness | Type I first | Validates controls before committing to observation period | | Buyer explicitly requires Type II | Type II | Match the buyer's requirement | | Budget constrained | Type I first | Lower initial cost | ## The Type I First Strategy Most startups follow this sequence: 1. Get audit-ready for Type I (4–6 weeks) 2. Complete Type I audit (2–3 weeks) 3. Start Type II observation period immediately 4. Complete Type II audit after 3–6 months This gives you a report to share with prospects within 6–8 weeks while you build the Type II track record in the background. ## When to Skip Type I Skip Type I if all three conditions are true: - You have had controls in place for 3+ months already - No prospect is waiting on your report right now - You want to avoid paying for two separate audits Some auditors offer a combined Type I + Type II engagement where they assess design (Type I) at the beginning of the observation period and operating effectiveness (Type II) at the end, issuing a single report. ## Cost Implications --- ### SOC 2 or ISO 27001: which should international companies get first? *Keywords: SOC 2 vs ISO 27001, international compliance, global certification* *Source: https://screenata.com/resources/answers/soc-2-or-iso-27001-which-should-international-companies-get-first* ## The Geographic Factor | Your Primary Market | Start With | Why | |---------------------|-----------|-----| | US buyers | SOC 2 | US enterprise standard for vendor security | | EU/UK buyers | ISO 27001 | European buyers expect ISO certification | | Asia-Pacific buyers | ISO 27001 | ISO is the recognized standard globally | | Both US and EU | SOC 2 first, then ISO | SOC 2 is faster; most controls reuse for ISO | | Government (any country) | Country-specific framework | FedRAMP (US), Cyber Essentials (UK), etc. | ## SOC 2 First: The Faster Path ## ISO 27001 First: When It Makes Sense | Situation | Why ISO First | |-----------|--------------| | All customers are in EU/UK | They specifically ask for ISO, not SOC 2 | | Pursuing EU government contracts | ISO often required | | Competitors have ISO but not SOC 2 | Match market expectations | | You want 3-year certification | ISO certifies for 3 years vs. SOC 2's annual reports | ## Doing Both: The Dual Path Many international SaaS companies pursue both. The efficient path: 1. **Start SOC 2** (faster, builds your control foundation) 2. **Begin ISO documentation** during the SOC 2 process (ISMS, SoA) 3. **Complete SOC 2** (3-4 months) 4. **Complete ISO 27001** using SOC 2 controls and evidence (2-4 additional months) Total timeline for both: 6-8 months instead of 12-16 months if done sequentially. ## Cost of Both The shared compliance tool and overlapping controls make pursuing both cheaper than the sum of individual costs. --- ### What are the 4 components of GRC? *Keywords: 4 components of GRC, GRC capability model, OCEG GRC model, learn align perform review, 4 components of GRC capability model* *Source: https://screenata.com/resources/answers/what-are-the-4-components-of-grc* ## What are the 4 components of GRC? The four components come from the **OCEG GRC Capability Model**: **Learn, Align, Perform, and Review**. Learn the context the organisation operates in, align objectives with risk appetite and obligations, perform the controls and activities that follow, then review whether any of it worked and feed the answer back. The model is a cycle rather than a sequence, and the review step is what makes it one. ### The four components | Component | What it covers | Typical artifact | |---|---|---| | **Learn** | Context, stakeholders, obligations, threats | Risk assessment, regulatory register | | **Align** | Objectives, risk appetite, resource decisions | Scope decisions, control matrix, policy set | | **Perform** | Controls, training, incident handling, monitoring | Evidence of controls operating | | **Review** | Effectiveness, findings, improvement | Internal audit results, corrective actions | ## The reading that causes confusion GRC stands for three things: governance, risk, and compliance. Asking for four components sometimes gets the answer "governance, risk, compliance, and audit", which is not a standard model and mixes a discipline in with three domains. The OCEG Capability Model is the answer with an actual source behind it, and it is more useful because it describes how a program runs rather than what it is called. ## Where a SOC 2 program sits Most compliance work happens in **Perform** and **Review**, which is also where most of the effort is wasted when the first two components are skipped. - **Learn** is the risk assessment. Skipping it means the control set is copied from a template rather than derived from what the business actually does. - **Align** is scoping. This is where trust services criteria get selected and controls get marked applicable or not. An unscoped program tests controls that never needed to apply. - **Perform** is controls operating across the observation period, producing evidence. - **Review** is monitoring, internal audit, and the external audit itself. The common failure is starting at Perform. A team that begins by collecting evidence, without having done Learn or Align, ends up with evidence for controls it did not need and gaps in the ones it did. ## Why the cycle matters more than the list The value of the model is the loop back from Review to Learn. A program that reviews and does not feed findings into the next cycle rediscovers the same gaps every year, which is the single most common pattern in compliance programs that have run for more than two audits. Perform is where most of the hours go, and it is the component that automates furthest. See [evidence collection](/product/evidence) for what that looks like when the collection runs on a schedule instead of before an audit. --- ### What are the 4 P's of BCP? *Keywords: 4 P's of BCP, business continuity planning, business impact analysis, people processes premises providers, five elements of a business impact analysis, three stages of BIA* *Source: https://screenata.com/resources/answers/what-are-the-4-ps-of-bcp* ## What are the 4 P's of BCP? The four P's of business continuity planning are **People, Processes, Premises, and Providers**. Each names a category of resource that a critical business function depends on: who does the work, how the work gets done, where it happens, and who you rely on outside the organisation. A business impact analysis works through all four for each critical function rather than stopping at technology. ### The four P's | P | The question it forces | What gets missed | |---|---|---| | **People** | Who can perform this function, and who else could? | Single points of knowledge with no documented process | | **Processes** | What steps and systems does it require? | Undocumented manual steps only one person knows | | **Premises** | Where does it happen, and what if that is unavailable? | Assumed remote-work capability that has never been tested | | **Providers** | Which suppliers does it depend on? | Fourth parties, the suppliers of your suppliers | ## Why the P's exist rather than a systems list Most continuity plans are written by technical teams and reflect that: they cover servers, backups, and failover regions. That work addresses part of Processes and part of Premises. It leaves People and Providers untouched. The gaps auditors and real incidents surface most often are in those two. A function that only one person knows how to perform is a continuity risk that no amount of infrastructure redundancy addresses. A critical supplier with no alternative is the same problem one step removed. ## Business impact analysis, and the two objectives it sets The BIA comes before the plan. It identifies critical functions, then determines for each how long it can be unavailable before the impact becomes unacceptable. That produces two numbers: - **RTO, recovery time objective.** How quickly the function must be restored. - **RPO, recovery point objective.** How much data loss is tolerable, measured in time. These two numbers are what a plan is designed against, and they are what an auditor asks for. A continuity plan with no stated RTO or RPO has not been designed against anything. The BIA is commonly described in three stages: identify critical functions, assess impact over time, and set recovery objectives. ## Where this appears in SOC 2 and ISO 27001 - **SOC 2 Availability** category: A1.2 covers environmental protections, backup, and recovery infrastructure; A1.3 requires testing recovery procedures. A Security-only scope does not test continuity directly. - **ISO 27001** Annex A 5.29 and 5.30 cover information security during disruption and ICT readiness for continuity. In both cases the artifact auditors ask for is the same: evidence the plan was **tested**, not merely written. An untested plan and no plan produce similar outcomes during an actual incident, and an auditor treats them similarly too. --- ### What are the 4 types of tests of controls? *Keywords: 4 types of tests of controls, inquiry observation inspection reperformance, SOC 2 testing methods, audit test of controls* *Source: https://screenata.com/resources/answers/what-are-the-4-types-of-tests-of-controls* ## What are the 4 types of tests of controls? The four types of tests of controls are **inquiry, observation, inspection, and reperformance**. They are the procedures an auditor uses to decide whether a control was designed properly and operated effectively, in SOC 2 examinations, SOX audits, and internal audit alike. Inquiry alone is never enough under auditing standards, so every conclusion rests on inquiry combined with at least one of the other three. ## The four tests, with SOC 2 examples | Test | What the auditor does | SOC 2 example | Evidence strength | |---|---|---|---| | Inquiry | Asks the control owner how the control works | Interviews the CTO about how production access is granted | Lowest; never sufficient alone | | Observation | Watches the control being performed | Watches an engineer request and receive production access | Point in time only | | Inspection | Examines records, documents, or configurations | Reviews access request tickets, approvals, and the IAM configuration | Strong, if the population is complete | | Reperformance | Independently executes the control | Pulls the user list from the identity provider and compares it with the reviewed list | Strongest | Observation has a known limit: it proves the control operated while the auditor was watching. For a Type II report covering a 3 to 12 month window, auditors lean on inspection of samples drawn across the whole period, because observation cannot reach backward in time. ## How auditors choose which test to use The choice depends on how the control operates. A manual control that leaves no record, such as a physical walkthrough, pushes the auditor toward observation. A control that produces tickets, approvals, or logs is tested by inspection of a sample. An automated control, such as a password configuration, is often tested once by inspection or reperformance, because a system setting behaves the same way every time it runs. Sample sizes follow frequency. A control that runs daily yields a larger sample than one that runs quarterly, and the auditor draws the sample from the full population your team provides. That is why the population itself gets scrutiny: a sample drawn from an incomplete list proves nothing about the missing items. ## What this means for the evidence you collect Every test type maps to an artifact you can prepare. Inquiry needs a named control owner who can explain the process. Inspection needs complete, timestamped records for the whole period. Reperformance needs the auditor to be able to reach the source data, or an export whose provenance they can trust. The weak point in most programs is inspection evidence assembled after the fact: screenshots taken the week before fieldwork, or exports with no record of when or how they were produced. Evidence captured at the time the control ran, with a timestamp and a record of the source, holds up under inspection and makes reperformance easier. For how auditors treat different evidence formats, see [why auditors reject CSV exports as evidence](/resources/answers/why-do-auditors-reject-csv-exports-as-evidence). --- ### What are the 5 basic security controls? *Keywords: 5 basic security controls, five basic security controls, CIS basic controls, cybersecurity basics for startups* *Source: https://screenata.com/resources/answers/what-are-the-5-basic-security-controls* ## What are the 5 basic security controls? The five basic security controls are **asset inventory, software inventory, secure configuration, vulnerability management, and control of administrative privileges**. They come from the CIS Controls, where they were the original Quick Wins because they remove the largest share of practical attack paths for the least effort. The phrase is often confused with the five functions of the NIST Cybersecurity Framework, which are Identify, Protect, Detect, Respond, and Recover. ### The five, in implementation order 1. **Inventory of hardware assets.** Know every device that connects. You cannot protect or decommission what nothing tracks. 2. **Inventory of software assets.** Know what runs on them, which is what makes patching and license risk tractable. 3. **Secure configuration.** Systems deployed to a hardened baseline rather than vendor defaults. 4. **Continuous vulnerability management.** Scan, prioritise, and remediate on a schedule that is written down. 5. **Controlled use of administrative privileges.** Few admins, separate accounts for admin work, and a record of who has them. These come from the **CIS Controls**, where the first group was originally published as the Quick Wins on the argument that they remove a disproportionate share of real-world attack paths relative to the effort they take. ## The list they get confused with The other common answer to "the five" is the **NIST Cybersecurity Framework functions**: Identify, Protect, Detect, Respond, Recover. Both lists are widely called the five, and they operate at different levels. | | CIS basic controls | NIST CSF functions | |---|---|---| | What it is | Five specific safeguards | Five categories organising a program | | Granularity | Implementable this quarter | Structural | | Use it to | Decide what to do first | Explain coverage to a board or auditor | | Answers | "What should we actually deploy?" | "Do we have all the bases covered?" | If a question is about what to implement, the CIS list is the useful answer. If it is about how to organise or report a program, NIST CSF is. ## What they cover in a SOC 2 audit The five basic controls map mostly onto the Common Criteria for logical access (CC6) and system operations (CC7). Administrative privilege control and asset inventory in particular do real work against CC6.1, CC6.2, and CC6.3. They do not get you a SOC 2 report. Missing from the list entirely: written policies, risk assessment, vendor management, change management, incident response, and the governance criteria in CC1 through CC5. The larger gap is that SOC 2 Type II tests whether a control **operated throughout a period**, so an inventory that exists today and was not maintained for the preceding six months produces an exception rather than a pass. ## Where to start if you are starting Administrative privileges first. It is the cheapest of the five, it removes the most immediate risk, and it produces evidence an auditor will ask for anyway. Asset and software inventory next, because the remaining two depend on knowing what exists. --- ### What are the 5 controls of Cyber Essentials? *Keywords: 5 controls of Cyber Essentials, Cyber Essentials requirements, NCSC Cyber Essentials, Cyber Essentials vs ISO 27001* *Source: https://screenata.com/resources/answers/what-are-the-5-controls-of-cyber-essentials* ## What are the 5 controls of Cyber Essentials? The five Cyber Essentials controls are **firewalls, secure configuration, user access control, malware protection, and security update management**. Cyber Essentials is a UK government-backed scheme run by the National Cyber Security Centre, and the five were chosen because together they block the large majority of commodity internet attacks. All five are technical; the scheme deliberately contains no governance requirements. ### The five controls | Control | What it requires | |---|---| | **Firewalls** | Boundary firewalls and correctly configured device firewalls between your network and the internet | | **Secure configuration** | Remove or disable unnecessary accounts, software, and services; change default passwords | | **User access control** | Accounts assigned to individuals, admin rights granted only where needed and reviewed | | **Malware protection** | Anti-malware, application allow-listing, or sandboxing on in-scope devices | | **Security update management** | Supported software only, with high and critical patches applied within 14 days | ## Cyber Essentials and Cyber Essentials Plus The controls are the same. The difference is verification. - **Cyber Essentials** is a self-assessment questionnaire, reviewed and verified by a certification body. - **Cyber Essentials Plus** adds hands-on technical testing by an assessor, including vulnerability scanning across a sample of devices. Plus takes longer and costs more, and it is what a buyer who cares about the difference will ask for. ## Where it stops The scheme's narrowness is intentional and it is also its limit. Cyber Essentials says nothing about: - Risk assessment and treatment - Policies, governance, or management accountability - Vendor and third-party risk - Incident response and business continuity - Personnel security, training, or background checks - Evidence that controls operated over a period rather than on the assessment date That last one is the structural difference from SOC 2 Type II. Cyber Essentials certifies a point in time. A Type II report tests whether controls operated throughout an observation period. ## When it is the right answer | Situation | Better fit | |---|---| | Bidding for UK public sector contracts | Cyber Essentials, often mandatory | | Small UK company wanting a credible first step | Cyber Essentials | | US enterprise buyer asking for assurance | SOC 2 | | International enterprise or tender requiring a certificate | ISO 27001 | | Healthcare data in the US | HIPAA, usually alongside SOC 2 | Cyber Essentials is a reasonable place to start and a poor place to stop if your buyers are enterprises. The five controls map onto parts of SOC 2 CC6 and CC7 and onto several ISO 27001 Annex A controls, so the work is not wasted when you move up. --- ### What are the 5 C's of compliance? *Keywords: 5 C's of compliance, five C's of compliance, compliance program fundamentals, elements of a compliance program* *Source: https://screenata.com/resources/answers/what-are-the-5-cs-of-compliance* ## What are the 5 C's of compliance? The 5 C's of compliance are **Commitment, Culture, Communication, Controls, and Continuous improvement**. They describe what makes a compliance program work in practice rather than on paper: leadership that funds and follows it, people willing to raise problems, policies that reach the people bound by them, safeguards that actually operate, and findings that feed back into the program. No standard defines them, so they are a teaching framework rather than a requirement. ### The five, and how each one fails Each names something a program needs in order to function, and each fails in a recognisable way when it is missing. | C | What it means | How it fails | |---|---|---| | Commitment | Leadership funds the program and follows it themselves | Policy says one thing, the executive team does another, and everyone notices | | Culture | People raise problems without fear of being blamed | Issues surface for the first time during the audit | | Communication | Policies reach the people who have to follow them | A policy exists that nobody outside the compliance owner has read | | Controls | Documented, operating safeguards with evidence behind them | Controls are described accurately but never actually run | | Continuous improvement | Findings feed back into the program | Every audit cycle rediscovers the same gaps | ## It is not an official standard No regulator, framework, or certification body defines the 5 C's. They are a mnemonic used in training and consulting, useful for explaining a program to an executive audience and not something an auditor will test you against. The list regulators do reference is the **seven elements of an effective compliance program**, set out in the US Federal Sentencing Guidelines and used by the HHS Office of Inspector General: written policies and procedures, a designated compliance officer with oversight, training and education, effective lines of communication, internal monitoring and auditing, enforcement of standards, and prompt response to detected problems. ## The confusion worth clearing up Search results mix two unrelated lists. - **5 C's of compliance:** Commitment, Culture, Communication, Controls, Continuous improvement. A program-level framework. - **5 C's of internal audit:** Criteria, Condition, Cause, Consequence, Corrective action. The structure of one audit finding, used to make an observation reportable. If someone in an audit meeting refers to the 5 C's, they almost always mean the second list. ## Where the 5 C's meet a real audit A SOC 2 or ISO 27001 auditor does not test Commitment or Culture directly. They test Controls, and the other four determine whether your controls survive testing. A control that exists in a document and never ran produces no evidence, and evidence is the only part of this an auditor can examine. That is why Continuous improvement is the one that most often breaks. Compliance treated as an annual project leaves controls to drift for eleven months, and the next audit starts by rediscovering last year's findings. --- ### What are the 5 C's of internal audit? *Keywords: 5 C's of internal audit, five C's of audit findings, audit finding structure, criteria condition cause consequence corrective action, 5 C's in auditing, five C's of audit* *Source: https://screenata.com/resources/answers/what-are-the-5-cs-of-internal-audit* ## What are the 5 C's of internal audit? The 5 C's of internal audit are **Criteria, Condition, Cause, Consequence, and Corrective action**. They are the structure of a single audit finding rather than a description of a program: what should be true, what is actually true, why the gap exists, what it puts at risk, and what will be done about it. A finding missing any of the five is usually sent back for rework before it can be reported. ### The five, with an example | C | The question it answers | Example | |---|---|---| | **Criteria** | What should be happening? | Policy requires access reviews each quarter | | **Condition** | What is actually happening? | Two of the last four quarters have no review record | | **Cause** | Why does the gap exist? | No owner was assigned after the previous owner left | | **Consequence** | What does it put at risk? | Departed employees may retain access; SOC 2 CC6.2 would fail | | **Corrective action** | What will be done, by whom, by when? | Ownership assigned to the CTO, reviews scheduled, first one completed by 30 September | ## Why the structure exists An audit finding has to survive two audiences. The person who has to fix it needs to know exactly what is wrong and what to do. The person who has to accept the risk needs to know what happens if nobody does. The five C's force both into a single paragraph. The structure is also what makes findings comparable across an audit. Ten findings written to the same shape can be ranked, tracked, and closed. Ten findings written as prose cannot. ## The one that gets skipped **Cause.** It is the hardest to establish and the easiest to leave out, and leaving it out is why findings recur. A missed access review whose cause is recorded as "the review was not performed" produces a corrective action of "perform the review." A missed access review whose cause is recorded as "no owner after a departure, and no process reassigns compliance tasks when someone leaves" produces a corrective action that prevents the next one. Consequence is the second weak point, usually because it is written as a restatement of the condition. "Access reviews were not performed" is a condition. "Terminated employees may retain production access for a full quarter" is a consequence. ## Where this shows up in SOC 2 and ISO 27001 External auditors use the same shape. A SOC 2 exception describes the criterion tested, the deviation observed, and its effect on the control objective. ISO 27001 nonconformities carry a required root cause analysis and corrective action, which is the same idea with the cause step made mandatory rather than optional. Writing internal findings in this structure means they translate directly when an external auditor asks what you already knew and what you did about it. --- ### What are the 5 pillars of DORA regulation? *Keywords: 5 pillars of DORA, DORA regulation, digital operational resilience act, DORA requirements for vendors* *Source: https://screenata.com/resources/answers/what-are-the-5-pillars-of-dora-regulation* ## What are the 5 pillars of DORA regulation? DORA's five pillars are **ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information and intelligence sharing**. The EU Digital Operational Resilience Act applies to financial entities operating in the EU and, through the third-party pillar, reaches the ICT providers that serve them. That is how it lands on software vendors who are not themselves financial institutions. ### The five pillars | Pillar | What it requires | |---|---| | **ICT risk management** | A governance framework with board accountability, identification of critical functions, protection and detection measures, and recovery arrangements | | **Incident management and reporting** | Classify ICT-related incidents against defined criteria and report major ones to regulators on set timelines | | **Resilience testing** | A testing programme, with threat-led penetration testing for entities designated as significant | | **Third-party risk management** | A register of ICT providers, contractual requirements including audit and access rights, concentration risk analysis, and documented exit strategies | | **Information sharing** | Voluntary exchange of cyber threat intelligence between financial entities | Four carry direct obligations. The fifth is encouraged rather than mandated. ## Why it reaches vendors who are not banks The third-party pillar is the one that travels. A regulated financial entity must impose specific contractual terms on its ICT providers, maintain a register of them, and be able to exit. Those obligations arrive at the vendor as procurement requirements: audit rights, subcontractor disclosure, incident notification timelines, and a documented exit plan. A SaaS company selling into EU financial services will therefore meet DORA through customer contracts and security reviews long before any regulator contacts it directly. ## DORA and NIS2 are not the same thing Both are EU, both concern operational resilience, and they are routinely conflated. | | DORA | NIS2 | |---|---|---| | Scope | EU financial entities and their ICT providers | Essential and important entities across many sectors | | Relationship | Sector-specific, takes precedence for financial entities | Broader baseline | | Distinctive requirement | Threat-led penetration testing, ICT provider register | Sector-wide risk measures and management accountability | ## Honest scope note Screenata supports SOC 2, HIPAA, ISO 27001, and ISO 42001 through a NIST 800-53 hub. **We do not currently support DORA or NIS2 as enrollable frameworks.** This page exists because the question is asked constantly by teams selling into EU financial services, and a straight answer is more useful than a gap left open. Much of the underlying evidence, particularly around vendor registers, incident handling, and resilience testing, overlaps with work an ISO 27001 or SOC 2 programme already produces. --- ### What are the 5 stages of third party management? *Keywords: 5 stages of third party management, vendor management lifecycle, third party risk management, TPRM stages, 5 pillars of vendor management, four third party risk types* *Source: https://screenata.com/resources/answers/what-are-the-5-stages-of-third-party-management* ## What are the 5 stages of third party management? The five stages are **planning and sourcing, due diligence and selection, contracting, ongoing monitoring, and termination or offboarding**. Together they describe a vendor relationship from before it exists to after it ends. The same lifecycle is often published as the five pillars of vendor management, and some frameworks split contracting from onboarding to make six, but the sequence does not change. ### The five stages | Stage | What happens | Evidence it produces | |---|---|---| | **Planning and sourcing** | Define the need, identify candidates, set risk criteria | Requirements, approved vendor criteria | | **Due diligence** | Assess security, compliance, and financial standing | Completed questionnaires, SOC 2 or ISO reports, review records | | **Contracting** | Negotiate terms including security obligations | Signed contract, DPA, BAA where PHI is involved | | **Ongoing monitoring** | Reassess on a cadence set by risk tier | Periodic review records, refreshed attestation reports | | **Termination** | Revoke access, retrieve or delete data, close the record | Offboarding checklist, access revocation evidence | ## The two stages that fail **Ongoing monitoring** fails because it has no natural trigger. Due diligence happens when someone wants to buy something, so it gets done. A reassessment twelve months later has nobody waiting on it. The usual result is a register full of vendors last reviewed on the day they were onboarded. **Termination** fails worse, because it happens after anyone cares. Access is not revoked, data is not retrieved, and the vendor remains in the register indefinitely. This is where auditors find the most durable findings, since a departed vendor with live API credentials is a concrete exposure rather than a paperwork gap. ## Risk tiering is what makes the lifecycle affordable Reviewing every vendor at the same depth is not achievable, and programs that try either stall or become theatre. Tiering by **data access and business criticality** is what makes it work: - **Critical:** processes production data or customer PII, or an outage stops the business. Annual review, SOC 2 or ISO report required. - **Moderate:** internal data, replaceable. Lighter review, longer cadence. - **Low:** no sensitive data access. Record the vendor, review at renewal. The four common risk categories a review considers are cybersecurity, compliance and regulatory, operational, and financial, with reputational often added as a fifth. Most real vendors present several at once, which is why tiering by access beats tiering by category. ## What SOC 2 and ISO 27001 test - **SOC 2** CC9.2 covers vendor and business partner risk management. The auditor asks for the vendor inventory, the criteria used to assess them, and evidence that reviews happened on the stated cadence. - **ISO 27001** Annex A 5.19 through 5.22 cover supplier relationships, agreements, ICT supply chain, and monitoring of supplier services. Both test the cadence more than the depth. A program that reviews critical vendors annually and can show the records will do better than one with elaborate questionnaires that were only ever completed once. The hard part is keeping the register current once the vendor count passes about thirty. See [vendor management](/product/vendors) for how vendors get discovered from your codebase and infrastructure config, risk-tiered, and put on a review cadence automatically. --- ### What are the 7 data policy principles? *Keywords: 7 data policy principles, 7 principles of data protection, GDPR Article 5 principles, GDPR data processing principles* *Source: https://screenata.com/resources/answers/what-are-the-7-data-policy-principles* ## What are the 7 data policy principles? The 7 data policy principles are the data protection principles in **Article 5 of the GDPR**: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Every use of personal data about people in the EU or UK must satisfy all seven. Breaching them is the most serious tier of GDPR infringement, carrying fines of up to 20 million euros or 4% of global annual turnover, whichever is higher. ## The seven principles, and how each one fails | Principle | What it requires | How it fails | |---|---|---| | Lawfulness, fairness and transparency | A valid legal basis for processing, and telling people what you do with their data | Collecting data under a privacy policy nobody could understand, or with no legal basis identified at all | | Purpose limitation | Use data only for the purposes you collected it for | Support emails quietly reused to train a model or feed a marketing list | | Data minimisation | Collect only what the purpose actually needs | A signup form demanding date of birth and phone number for a newsletter | | Accuracy | Keep personal data correct and up to date | Decisions made on stale records with no way for people to correct them | | Storage limitation | Keep data no longer than the purpose requires | No retention schedule; every record kept forever by default | | Integrity and confidentiality | Protect data with appropriate security | A breach traced to an unencrypted export or an access control nobody reviewed | | Accountability | Be able to demonstrate compliance with the other six | Practices may even be fine, but nothing is documented, so nothing can be proven | ## Which list of principles you actually mean Three similar-sounding lists circulate, and search results blend them. Resolving which one you need matters because only one of them is current law. **The 7 GDPR principles** (this page) are Article 5 of the EU GDPR, in force since 25 May 2018, and mirrored in the UK GDPR. This is what "the 7 principles of data protection" means today. **The 8 principles of the Data Protection Act 1998** were the previous UK regime. The list overlaps heavily but has eight entries, including a standalone principle on international transfers. The 1998 Act was repealed when GDPR took effect, so an eight-item list is a sign the source is out of date. **The 7 foundational principles of Privacy by Design** come from Ann Cavoukian's 1990s framework: proactive not reactive, privacy as the default setting, privacy embedded into design, and so on. It is a design philosophy, not legislation. GDPR adopted the concept in Article 25 as data protection by design and by default, which is why the two get merged in casual usage, but the seven Cavoukian principles are not the seven Article 5 principles. ## Accountability is the one that generates the paperwork Six of the principles describe how data should be handled. Accountability is different: it requires you to be able to **demonstrate** compliance with the other six. That single word is where most GDPR paperwork originates. Records of processing activities under Article 30, data processing agreements with every vendor that touches personal data, a privacy policy that matches reality, retention schedules, and data protection impact assessments for higher-risk processing all exist to satisfy accountability. This is also why a company can follow the first six principles in practice and still be exposed. A regulator investigating a complaint asks for the documentation first. If minimisation and storage limitation are genuinely observed but never written down, there is no evidence to show, and accountability is itself breached. For teams that already run a security compliance program, the useful framing is that the GDPR principles behave like control objectives: each one implies documents, decisions, and records that must exist and stay current, and the demonstration matters as much as the practice. --- ### What are the 7 documents your SOC 2 auditor actually needs? *Keywords: SOC 2 documents, auditor requirements, SOC 2 deliverables* *Source: https://screenata.com/resources/answers/what-are-the-7-documents-your-soc-2-auditor-actually-needs* ## The Seven Core Documents Auditors don't want a hundred documents. They want a focused set that covers the Trust Services Criteria in your scope. Here are the seven that every SOC 2 audit requires: | # | Document | Maps To | What It Covers | |---|----------|---------|----------------| | 1 | Information Security Policy | CC1.1-CC1.5 | Overall security program, roles, responsibilities | | 2 | Access Control Policy | CC6.1-CC6.8 | Who gets access, how, and approval process | | 3 | Change Management Policy | CC8.1 | How code changes are approved and deployed | | 4 | Incident Response Plan | CC7.3-CC7.5 | How you detect, respond to, and recover from incidents | | 5 | Risk Assessment | CC3.1-CC3.4 | Identified risks and how you mitigate them | | 6 | Vendor Management Policy | CC9.1-CC9.2 | How you evaluate and monitor third-party vendors | | 7 | System Description | Section 3 | Your infrastructure, data flows, and boundaries | ## What Each Document Needs Every document should include: the purpose of the policy, who it applies to, the specific controls you follow, how you monitor and enforce the controls, and when the policy was last reviewed. The most critical thing: each document must describe your *actual* systems and processes. If your change management policy says "all deployments require two reviewer approvals" but your GitHub repo allows one, the auditor will flag that mismatch. ## Common Mistakes - **Too many documents:** Some consultants create 20-30 policies. Auditors don't need that. Seven well-written documents cover the criteria. - **Too generic:** Policies that say "the company uses industry-standard encryption" without specifying which encryption. Name your systems. - **Outdated:** Policies written six months ago that don't reflect current infrastructure. Review before audit. ## Where Screenata Helps Screenata generates these seven documents by reading your codebase and cloud infrastructure. Each policy references your actual tools and configurations, so they match what the auditor will observe during testing. --- ### What are the 7 pillars of compliance? *Keywords: 7 pillars of compliance, seven elements of an effective compliance program, OIG seven elements, federal sentencing guidelines compliance program* *Source: https://screenata.com/resources/answers/what-are-the-7-pillars-of-compliance* ## What are the 7 pillars of compliance? The seven pillars of compliance are **written policies and procedures, a designated compliance officer and oversight, training and education, effective lines of communication, internal monitoring and auditing, enforcement of standards, and prompt response to detected problems**. Unlike most numbered compliance lists, this one has an authoritative source: the US Federal Sentencing Guidelines, adopted by the HHS Office of Inspector General as the seven elements of an effective compliance program. ### The seven, in order 1. **Written policies, procedures, and standards of conduct.** The documented rules, available to the people expected to follow them. 2. **A designated compliance officer and compliance committee.** Named accountability with enough authority and budget to act. 3. **Effective training and education.** Delivered to the people whose work the policies govern, and recorded. 4. **Effective lines of communication.** A route for raising concerns, usually including an anonymous one. 5. **Internal monitoring and auditing.** Checking that controls actually operate, rather than assuming they do. 6. **Enforcement of standards through well-publicised disciplinary guidelines.** Consequences that are known in advance and applied consistently. 7. **Prompt response to detected offences and corrective action.** Investigating, fixing, and preventing recurrence. ## Why this list carries weight Most numbered compliance frameworks are teaching devices with no authority behind them. This one is different. It comes from the **US Federal Sentencing Guidelines**, and it matters because prosecutors and regulators use it to judge whether an organisation's compliance program was real or decorative. The HHS Office of Inspector General adopted the same seven elements in its compliance program guidance, which is why the list is most familiar in healthcare. That gives the seven pillars a practical use the 5 C's do not have: they are a defensible structure to organise a program around when someone external is deciding whether you took compliance seriously. ## How the pillars map to an audit | Pillar | What a SOC 2 or ISO 27001 auditor asks for | |---|---| | Written policies | The policy set, with version history and evidence of approval | | Compliance officer | Named owner, role description, evidence of oversight activity | | Training | Completion records per person, per period | | Lines of communication | The reporting channel and records of what came through it | | Monitoring and auditing | Control test results across the observation period | | Enforcement | Documented disciplinary standards, applied consistently | | Response | Incident records showing investigation and corrective action | Five of the seven produce evidence an auditor can sample. That is the useful way to read the list: each pillar has an artifact behind it, and a pillar with no artifact is an assertion. ## Seven pillars, seven elements, or seven components All three names refer to the same list. The OIG uses elements. Consultants often say pillars. Nothing turns on the difference. --- ### What are the 7 principles of privacy? *Keywords: 7 principles of privacy, seven principles of GDPR, privacy by design principles, GDPR Article 5 principles, 7 data protection principles, 7 data policy principles* *Source: https://screenata.com/resources/answers/what-are-the-7-principles-of-privacy* ## What are the 7 principles of privacy? Two different lists carry this name. **GDPR Article 5** sets out seven data protection principles: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. **Privacy by Design**, developed by Ann Cavoukian, sets out seven foundational principles for building privacy into systems. GDPR Article 5 is legally binding. Privacy by Design is a design philosophy that GDPR Article 25 partly codifies. Which one you want depends on whether the context is legal or architectural. ## GDPR Article 5: the seven data protection principles | Principle | What it requires | |---|---| | Lawfulness, fairness, transparency | A valid legal basis, and people are told what happens to their data | | Purpose limitation | Collected for a stated purpose, not reused for an incompatible one | | Data minimisation | Only what the purpose actually needs | | Accuracy | Kept correct and updated, with a route to correction | | Storage limitation | Retained only as long as the purpose requires | | Integrity and confidentiality | Protected against unauthorised access, loss, and damage | | Accountability | You can **demonstrate** the other six, not just satisfy them | Accountability is the one that changes daily work. It converts every other principle into something that needs a record behind it, which is why GDPR programs generate documentation the way they do. ## Privacy by Design: the seven foundational principles 1. Proactive not reactive, preventative not remedial 2. Privacy as the default setting 3. Privacy embedded into design 4. Full functionality, a positive-sum rather than zero-sum outcome 5. End-to-end security across the full data lifecycle 6. Visibility and transparency, open to independent verification 7. Respect for user privacy, keeping it user-centric Developed by Ann Cavoukian while Information and Privacy Commissioner of Ontario. It is a design philosophy rather than law, though GDPR **Article 25** gives part of it legal force under data protection by design and by default. ## Which one to cite | Situation | Use | |---|---| | Regulator, auditor, or DPA question | GDPR Article 5 | | Security questionnaire from an enterprise buyer | GDPR Article 5 | | Engineering decisions about handling data | Privacy by Design | | Explaining your approach to customers | Privacy by Design, with Article 5 for substantiation | Citing the wrong one is not an error so much as a mismatch. A regulator asking about your principles wants Article 5. An engineer asking wants principles that survive contact with a schema design. ## How this connects to SOC 2 and ISO 27001 SOC 2 has an optional **Privacy** trust services category, and ISO 27701 extends ISO 27001 into a privacy information management system. Neither uses either list of seven verbatim, but both test the same underlying obligations: a lawful basis, minimisation, retention limits, protection, and the ability to demonstrate all of it. Accountability is again the criterion that generates the evidence. --- ### What are four consequences of non-compliance? *Keywords: consequences of non-compliance, four consequences of non-compliance, three consequences of non-compliance, cost of non-compliance* *Source: https://screenata.com/resources/answers/what-are-the-consequences-of-non-compliance* ## What are four consequences of non-compliance? The four main consequences of non-compliance are **fines and penalties, legal liability, lost business, and reputational damage**. Fines come from regulators. Legal liability comes from lawsuits, contract claims, and occasionally criminal charges. Lost business comes from customers and partners who will not buy from, or keep working with, a non-compliant vendor. Reputational damage follows any public enforcement action or breach, and it usually costs more over time than the penalty itself. ## The four consequences with examples The CCPA figures are the inflation-adjusted amounts effective January 1, 2025. HIPAA figures are the 2026 adjustments that apply to penalties assessed on or after January 28, 2026. ## Legal requirements versus voluntary frameworks The consequences depend on whether the requirement is a law or a commitment. | Requirement | Is it law? | Main consequence of non-compliance | |---|---|---| | GDPR, CCPA, HIPAA, NYDFS Part 500 | Yes | Regulatory fines, legal liability, mandatory corrective action | | PCI DSS | No, contractual through card networks | Fines passed through by the acquiring bank, loss of the ability to process cards | | SOC 2, ISO 27001 | No, voluntary | Lost deals and failed customer security reviews | For a B2B software company, the voluntary frameworks often bite first. A startup selling to enterprises will meet a SOC 2 requirement in procurement long before it meets a regulator, and the consequence of not having one is measured in deals rather than fines. ## Operational consequences that are easy to miss Beyond the four headline consequences, non-compliance creates ongoing costs. Regulators commonly impose corrective action plans that last years and require outside monitoring. Breach notification carries its own costs: legal counsel, forensic investigation, notification letters, and credit monitoring for affected individuals. Insurers raise premiums or decline cyber coverage for companies with known control gaps. The pattern across regimes is that the fine is rarely the largest cost. The larger costs are the remediation performed under a regulator's supervision and the revenue lost while it happens. For the HIPAA case specifically, see [whether you can go to jail for violating HIPAA](/resources/answers/can-you-go-to-jail-for-violating-hipaa). --- ### What are the five risk mitigation strategies? *Keywords: five risk mitigation strategies, risk treatment options, avoid reduce transfer accept, ISO 31000 risk treatment, 5 steps of the ORM process, 5 parts of ORM, three main mitigation strategies* *Source: https://screenata.com/resources/answers/what-are-the-five-risk-mitigation-strategies* ## What are the five risk mitigation strategies? The five risk mitigation strategies are **avoid, reduce, transfer, accept, and share**. Avoid removes the activity that creates the risk. Reduce applies controls that lower likelihood or impact. Transfer moves the financial consequence to another party, usually an insurer. Accept documents a deliberate decision to tolerate the risk. Share distributes it across several parties. Every risk in a register ends up with one of these five attached to it. ### The five strategies | Strategy | What you do | Example | |---|---|---| | **Avoid** | Stop or never start the activity | Decline to store card data at all | | **Reduce** | Apply controls that lower likelihood or impact | Enforce MFA, encrypt at rest, run backups | | **Transfer** | Move the financial consequence elsewhere | Cyber insurance, contractual indemnity | | **Accept** | Document a decision to tolerate it | Accept the residual risk of a legacy system due for decommission | | **Share** | Distribute across parties | A joint venture where both parties carry part of the exposure | ## Four or five Some frameworks list four by folding **share** into **transfer**, and the two are genuinely close. The distinction is that transfer moves consequence to someone whose business is absorbing it, while sharing splits it among parties who all carry part of the outcome. **ISO 31000** uses different vocabulary for the same set, describing risk treatment options that include avoiding the risk, removing the source, changing likelihood, changing consequences, sharing, and retaining. The mapping is direct even though the words differ, so a register built on either vocabulary satisfies the other. ## Operational risk management, the five-step version A related list answers "the 5 steps of the ORM process", which is a different thing: a procedure rather than a set of options. 1. Identify hazards 2. Assess the hazards 3. Make risk decisions 4. Implement controls 5. Supervise and review The five mitigation strategies are what step 3 chooses between. Confusing the two lists is common because both are five items and both use the word risk. ## What an auditor actually tests Not whether you chose the right strategy. Auditors test whether the decision was **made, recorded, and owned**. - Every risk in the register has a treatment recorded against it - The person who accepted a risk had the authority to accept it - Residual risk is stated after treatment, not just inherent risk - Treatments that were decided actually got implemented Acceptance is the one that surprises people. Accepting a risk is entirely legitimate and auditors see it constantly. What fails is an *undocumented* acceptance, because from the outside it looks identical to having missed the risk altogether. This is also the most common gap in a young risk register: risks are listed with owners and treatment plans, and the inherent and residual scores are blank. --- ### What are the four types of security policies? *Keywords: four types of security policies, types of information security policies, NIST SP 800-12 policy types, security policies for SOC 2* *Source: https://screenata.com/resources/answers/what-are-the-four-types-of-security-policies* ## What are the four types of security policies? The four types of security policies are **program (organizational) policy, issue-specific policies, system-specific policies, and standards, procedures, and guidelines** as the supporting layer. The taxonomy comes from NIST SP 800-12, the US National Institute of Standards and Technology's introduction to information security. Program policy establishes the security program itself, issue-specific policies address one topic each, system-specific policies govern one system each, and the supporting layer turns all of them into enforceable specifics. ## The four types, with examples For a SaaS company, each type maps to documents you would recognize. | Type | Scope | Example for a SaaS company | Who approves | |---|---|---|---| | Program policy | The entire organization's security program | Information security policy establishing the program, its owner, and its authority | CEO or board | | Issue-specific policy | One topic, across the whole company | Acceptable use, access control, incident response, vendor management | CISO, CTO, or equivalent executive | | System-specific policy | One system or environment | Production access policy for the main cloud environment | System owner | | Standards, procedures, guidelines | Implements the policies above | Password standard (minimum 12 characters, MFA required); offboarding procedure | Policy owner or security team | The layers are hierarchical. The program policy says security is mandatory and names who runs it. An issue-specific policy says all access follows least privilege. A system-specific policy says who may access production and how. A standard says exactly what a compliant password looks like. Reading top to bottom, each layer answers the question the layer above left open. ## Three types or four? Sources disagree on the count, and the disagreement is worth resolving because both numbers appear in training materials and exam guides. NIST SP 800-12 formally defines **three** types of policy: program, issue-specific, and system-specific. It discusses standards, procedures, and guidelines separately, as documents that implement policy rather than policy proper. Later textbooks and certification courses folded that supporting layer in as a fourth type because in practice the documents live together and are managed the same way. So "three types" and "four types" describe the same structure. If an exam or an auditor asks, the distinction that matters is between the three policy layers, which state management's intent, and the supporting layer, which specifies how that intent is carried out. Policies change rarely and need executive approval; standards and procedures change often and should not need a board meeting to update. ## What SOC 2 auditors expect from a policy set SOC 2 does not mandate this taxonomy or any fixed list of documents. What auditors test is whether your policy set covers the Trust Services Criteria in scope and whether the documents are real: **versioned**, **formally approved** by someone with the authority to bind the organization, **acknowledged** by employees, and **reviewed at least once every 12 months**. The common failure is not a missing policy type. It is a complete-looking policy set with no operating history behind it: no approval records, no acknowledgment trail, and a last-reviewed date from two years ago. An auditor treats an unapproved policy as no policy, because a document nobody signed binds nobody. A practical way to build the set is top-down in the NIST order. Write the program policy first, since every other document inherits its authority. Then write issue-specific policies against the criteria your audit covers. Add system-specific policies only where a system genuinely needs rules of its own, and push everything volatile, such as password parameters and tool configurations, down into standards so routine changes never require re-approving a policy. --- ### What are the three main ISMS pillars? *Keywords: three main ISMS pillars, ISMS people processes technology, information security management system, ISMS vs CIA triad* *Source: https://screenata.com/resources/answers/what-are-the-three-main-isms-pillars* ## What are the three main ISMS pillars? The three main pillars of an ISMS are **people, processes, and technology**. An information security management system is the organized way a company manages security risk, and the pillars describe what it is made of: trained and accountable humans, documented and repeated procedures, and tools that enforce and monitor controls. Security failures trace back to a weak pillar far more often than to a missing product, which is why the model persists. No single pillar can compensate for the other two. ## Untangling the question first People searching "what are the three main ISMS" are usually asking one of three different things, so it is worth separating them: - **The three pillars of an ISMS**: people, processes, technology. This page's subject, and what the phrase almost always means. - **The CIA triad**: confidentiality, integrity, availability. These are the three objectives an ISMS protects, defined in ISO 27000's vocabulary. They are properties of information, not components of a management system. - **ISO 27001**: the certifiable international standard for building and operating an ISMS. It is one standard, not three, and it does not use the word "pillars" anywhere. The pillars and the CIA triad get merged in search results because both are security triads. The clean distinction: the CIA triad is what you protect, the pillars are what you protect it with. ## The three pillars in practice | Pillar | What it covers | How it fails | |---|---|---| | People | Hiring screening, security training, defined roles and ownership, offboarding, accountability | An employee reuses a breached password, or nobody owns access reviews so departed staff keep credentials | | Processes | Policies, risk assessments, incident response procedures, change management, periodic reviews | The incident response plan exists as a document nobody has rehearsed, so the first real incident is improvised | | Technology | Access control, encryption, logging and monitoring, endpoint protection, backups | Tools are bought but half-configured; alerts fire into a channel nobody reads | The failure column is the point of the model. Most organizations over-invest in the technology pillar because it is purchasable, while the people and process pillars require sustained management attention. An ISMS is the mechanism that forces attention onto all three: it assigns owners (people), mandates recurring activities like risk assessments and access reviews (processes), and requires evidence that tools actually operate (technology). ## Where ISO 27001 fits ISO 27001 is the standard you certify an ISMS against, and its structure confirms the pillar model without naming it. The 2022 edition of its control set (Annex A, drawn from ISO 27002) contains 93 controls in four themes: organizational (37 controls), people (8), physical (14), and technological (34). People and technological themes map directly onto two pillars; organizational controls are mostly process; and physical controls are the one area the three-pillar shorthand undersells, which is why some teachings add "physical" as a fourth pillar. Certification is also where the pillars stop being a metaphor. An ISO 27001 auditor samples all of them: training records and role definitions for people, documented and executed procedures for process, and configuration and log evidence for technology. A company strong in one pillar and absent in another does not pass, because the standard audits the management system as a whole. ## Why the model is useful beyond ISO 27001 The pillars apply to any security program, certified or not. SOC 2's Trust Services Criteria test the same three surfaces: personnel controls, documented processes, and technical safeguards. If you are building a program from nothing, the pillars are a reasonable order of operations check: for each risk you care about, ask who owns it, what procedure addresses it, and what tool enforces it. A risk with answers in only one column is the gap an auditor, or an attacker, finds first. --- ### What are the three rules under HIPAA? *Keywords: three rules under HIPAA, HIPAA privacy security breach notification, HIPAA rules explained, HIPAA safeguards, four safeguards HIPAA, 5 steps towards HIPAA compliance* *Source: https://screenata.com/resources/answers/what-are-the-three-rules-under-hipaa* ## What are the three rules under HIPAA? The three main rules are the **Privacy Rule**, the **Security Rule**, and the **Breach Notification Rule**. The Privacy Rule governs how protected health information may be used and disclosed in any form, including paper and spoken. The Security Rule applies specifically to electronic PHI and requires administrative, physical, and technical safeguards. The Breach Notification Rule governs what you must do, and within what deadlines, once PHI has been exposed. ### The three, and what each one governs | Rule | Scope | Core requirement | |---|---|---| | **Privacy Rule** | PHI in any form | Limits on use and disclosure, minimum necessary standard, patient rights of access | | **Security Rule** | Electronic PHI only | Administrative, physical, and technical safeguards, plus risk analysis | | **Breach Notification Rule** | Unsecured PHI after exposure | Notify individuals without unreasonable delay and no later than 60 days; notify HHS; notify media for breaches affecting 500 or more people in a state | ## The two that are often counted as well - **Enforcement Rule.** Investigation procedures, hearings, and the civil monetary penalty tiers. - **Omnibus Rule (2013).** Extended direct liability to business associates and their subcontractors, which is why a vendor handling PHI now signs a BAA and carries obligations of its own rather than only contractual ones. Counting these gives five rules. Three is the usual answer because Privacy, Security, and Breach Notification are the ones that impose day-to-day obligations. ## The safeguards question The Security Rule defines **three safeguard categories**: - **Administrative:** risk analysis, workforce training, access management, contingency planning - **Physical:** facility access, workstation use and security, device and media controls - **Technical:** access control, audit controls, integrity controls, transmission security Some sources answer "four safeguards" by adding **organisational requirements**, which the rule does list separately, alongside policies, procedures, and documentation requirements. Both counts are defensible, which is why the question returns inconsistent answers. The three-category version is the one the rule structures itself around. ## What this means for a compliance program HIPAA has no certification. There is no HIPAA certificate to obtain, and any vendor selling one is selling an attestation of their own making. What organisations do instead is demonstrate compliance through a documented risk analysis, implemented safeguards, signed business associate agreements, and evidence that all of it operates. That is why HIPAA work overlaps heavily with SOC 2. The Security Rule safeguards map closely onto the SOC 2 Common Criteria, particularly CC6 for access control and CC7 for operations, so evidence collected once frequently satisfies both. If you are working out whether the rules apply to you and what the safeguards mean in practice, see [HIPAA compliance for startups](/solutions/hipaa). To check which of the tools you already use will sign a BAA, see [BAA status by tool](/hipaa). --- ### What are the three types of security controls? *Keywords: three types of security controls, administrative technical physical controls, preventive detective corrective controls, examples of operational controls* *Source: https://screenata.com/resources/answers/what-are-the-three-types-of-security-controls* ## What are the three types of security controls? The three types of security controls are **administrative, technical, and physical**, grouped by how a control is implemented. A second common set of three groups controls by when they act: **preventive, detective, and corrective**. Both lists are correct because they measure different things, and every control has a type on each axis. Multi-factor authentication, for example, is both technical and preventive. ## By implementation: administrative, technical, physical | Type | What it is | Examples | |---|---|---| | Administrative | Policies, procedures, and people-run processes | Security policies, training, background checks, access reviews, vendor assessments | | Technical | Controls enforced by hardware or software | MFA, encryption, firewalls, logging, endpoint protection | | Physical | Controls on physical access to facilities and devices | Badge readers, locked server rooms, cameras, device disposal | This is the grouping the HIPAA Security Rule uses for its administrative, physical, and technical safeguards. Administrative controls are sometimes called managerial controls, and older NIST guidance split them further into management and operational classes. ## By function: preventive, detective, corrective | Type | When it acts | Examples | |---|---|---| | Preventive | Before an incident, to stop it | MFA, least-privilege access, code review before merge | | Detective | During or after, to surface it | Log alerts, intrusion detection, access reviews, vulnerability scans | | Corrective | After, to limit damage and restore | Incident response, restoring from backup, revoking a compromised key | Some frameworks extend this list with deterrent controls (warning banners), recovery controls (disaster recovery), and compensating controls (an alternative used when the standard control is not feasible). The three above are the core. ## How the two axes combine Reading a control on both axes shows where a program is thin. A company with strong preventive technical controls but no detective controls will not know when prevention fails. A program heavy on administrative controls with few technical ones depends on people following documents. | Control | By implementation | By function | |---|---|---| | MFA on the identity provider | Technical | Preventive | | Quarterly user access review | Administrative | Detective | | Branch protection requiring pull request approval | Technical | Preventive | | Incident response plan | Administrative | Corrective | | Badge access to the office | Physical | Preventive | SOC 2 does not require either classification, but auditors expect a mix. In practice, detective administrative controls such as access reviews generate the most evidence requests, because they run periodically and the auditor samples each occurrence. For how auditors test those occurrences, see [the four types of tests of controls](/resources/answers/what-are-the-4-types-of-tests-of-controls). --- ### What are Trust Services Criteria and which ones should I pick? *Keywords: Trust Services Criteria, SOC 2 criteria selection, Security vs Availability* *Source: https://screenata.com/resources/answers/what-are-trust-services-criteria-and-which-ones-should-i-pick* ## What Are Trust Services Criteria? Trust Services Criteria (TSC) are the five categories the AICPA uses to evaluate your controls during a SOC 2 audit. Security is required for every SOC 2 engagement. The other four are optional and should be added only when your customers or contracts require them. ## The Five Criteria Explained | Criterion | What It Covers | When to Include | |-----------|---------------|-----------------| | **Security** (CC) | Protection against unauthorized access, system boundaries, risk management | Always, required for every SOC 2 | | **Availability** (A) | System uptime, disaster recovery, performance monitoring | When you have SLA commitments | | **Processing Integrity** (PI) | Data processing accuracy and completeness | When you process financial or transactional data | | **Confidentiality** (C) | Protection of confidential data (not personal data) | When you handle trade secrets or NDA-covered data | | **Privacy** (P) | Collection, use, retention, and disposal of personal information | When you process PII under privacy commitments | ## Which Should You Pick for Your First Audit? Start with **Security only**. Here is why: 1. Security covers 80% of what enterprise buyers evaluate in vendor reviews 2. Every additional criterion adds 15–30% more evidence collection work 3. Most buyers accept a Security-only report for initial vendor approval 4. You can add criteria in your next audit cycle once you know what customers actually request ## When to Add More Criteria Add Availability if you have contractual SLAs (99.9% uptime guarantees). Add Processing Integrity if you handle financial transactions or billing data. Add Confidentiality if your contracts include data classification requirements. Add Privacy only if you process consumer personal data under explicit privacy commitments, most B2B SaaS companies do not need it. ## A Common Mistake Some consultants recommend adding all five criteria to your first audit. This increases scope, cost, and timeline without matching what buyers actually require. Ask your top three enterprise prospects which criteria they need. The answer is almost always just Security. Screenata helps you scope your SOC 2 audit correctly and generates evidence mapped to the specific Trust Services Criteria you select. --- ### What controls overlap between SOC 2, ISO 27001, and HIPAA? *Keywords: SOC 2 ISO 27001 overlap, framework overlap, shared controls* *Source: https://screenata.com/resources/answers/what-controls-overlap-between-soc-2-iso-27001-and-hipaa* ## Control Overlap Map | Control Area | SOC 2 | ISO 27001 | HIPAA | |-------------|-------|-----------|-------| | Access control (MFA, RBAC) | CC6.1-6.8 | A.9 | §164.312(a) | | Change management | CC8.1 | A.14 | §164.312(e) | | Incident response | CC7.3-7.5 | A.16 | §164.308(a)(6) | | Risk assessment | CC3.1-3.4 | Clause 6.1 | §164.308(a)(1) | | Encryption | CC6.7 | A.10 | §164.312(a)(2)(iv) | | Logging and monitoring | CC7.1-7.2 | A.12.4 | §164.312(b) | | Vendor management | CC9.1-9.2 | A.15 | §164.308(b) | | Security training | CC1.4 | A.7.2 | §164.308(a)(5) | | Data backup | A1.2 | A.12.3 | §164.308(a)(7) | | Physical security | CC6.4 | A.11 | §164.310 | ## What Each Framework Adds Uniquely ### SOC 2 Only - Trust Services Criteria flexibility (choose which criteria to include) - System description requirement (Section 3) - CPA attestation model ### ISO 27001 Only - Formal ISMS (Information Security Management System) requirement - Statement of Applicability document - Management review process - Continual improvement mandate ### HIPAA Only - PHI-specific data handling rules - Business Associate Agreement requirements - Breach notification (60-day timeline) - Minimum necessary standard (only access PHI needed for the task) - Patient rights (access, amendment, accounting of disclosures) ## Building on SOC 2 If you start with SOC 2 and then pursue ISO 27001 or HIPAA: | Adding to SOC 2 | Additional Work | Timeline | |-----------------|----------------|----------| | + ISO 27001 | ISMS documentation, Statement of Applicability, management review process | 2-4 months | | + HIPAA | BAA template, PHI data mapping, breach notification process, privacy controls | 1-2 months | | + Both | Combined additional work | 3-5 months | The shared controls (access, encryption, change management, incident response) don't need to be re-implemented, just mapped to the new framework's requirements. --- ### What do enterprise security teams actually evaluate before approving a vendor? *Keywords: enterprise vendor evaluation, security review checklist, vendor approval criteria* *Source: https://screenata.com/resources/answers/what-do-enterprise-security-teams-actually-evaluate-before-approving-a-vendor* ## The Enterprise Vendor Evaluation Process When you sell to enterprise companies, your product goes through a security review before they sign. The security team (or InfoSec, or GRC team) evaluates whether your product is safe to use with their data. ## What They Look For | Evaluation Area | What They Check | How You Prove It | |----------------|-----------------|-----------------| | Compliance posture | SOC 2 report, ISO 27001 cert | Provide your audit report | | Data handling | Where data is stored, encryption, retention | Security questionnaire answers | | Access controls | How you protect their data from unauthorized access | SOC 2 report + questionnaire | | Incident history | Past breaches or security incidents | Self-disclosure, news search | | Business continuity | Backup, disaster recovery, uptime SLA | Availability criteria in SOC 2 | | Insurance | Cyber liability insurance coverage | Certificate of insurance | | Subprocessors | Third-party services that touch their data | Vendor list with their compliance status | ## The SOC 2 Shortcut A current SOC 2 Type II report answers 60-80% of a typical security questionnaire. Enterprise teams accept it because: - It's independently audited (not self-reported) - It covers standard security controls comprehensively - It's a recognized standard across industries - It reduces their evaluation time from weeks to days ## Without SOC 2 Without a SOC 2 report, you'll face: - A 50-100 question security questionnaire - Multiple rounds of follow-up questions - Requests for screenshots and documentation - A 2-6 week evaluation timeline - Possible rejection from risk-averse buyers ## What Enterprise Teams Care About Most 1. **Data encryption** (at rest and in transit), non-negotiable 2. **Access controls** (MFA, RBAC, least privilege), heavily scrutinized 3. **Incident response** (do you have a plan?), always asked 4. **Data residency** (where is data stored?), especially for regulated industries 5. **SOC 2 report** (current, Type II preferred), the gold standard ## The Revenue Impact --- ### What does a compliance consultant actually do for SOC 2? *Keywords: compliance consultant SOC 2, what does vCISO do, SOC 2 consultant scope* *Source: https://screenata.com/resources/answers/what-does-a-compliance-consultant-actually-do-for-soc-2* ## What Does a Compliance Consultant Do? A compliance consultant is the person who translates SOC 2 requirements into actions for your team. They know what auditors expect, what evidence satisfies each criterion, and how to avoid common mistakes. For most startups, the consultant is the difference between a smooth audit and a painful one. ## Typical Engagement Scope | Phase | What the Consultant Does | Your Team's Role | |-------|-------------------------|-----------------| | Discovery | Interviews your team, reviews infrastructure | Provide access and answer questions | | Gap assessment | Identifies missing controls and documentation | Review findings | | Policy writing | Writes or reviews 4–7 security policies | Approve and sign policies | | Control mapping | Maps your controls to Trust Services Criteria | Confirm controls are accurate | | Evidence planning | Creates an evidence collection checklist | Collect the evidence | | Readiness review | Simulates auditor testing | Fix remaining gaps | | Audit support | Coordinates with the auditor, joins walkthrough calls | Participate in meetings | ## What You Get at the End A good consultant delivers: - Written policies tailored to your infrastructure - A controls matrix mapping each control to TSC criteria - An evidence collection plan with specific artifacts needed - A readiness report with any remaining gaps - Audit coordination and walkthrough preparation ## The Problem With Consultants for Startups ## When a Consultant Makes Sense If you are pursuing multiple compliance frameworks, have a large and complex infrastructure, or need someone to own the program long-term, a consultant is worth the investment. For a straightforward SOC 2 Type I with Security scope, Screenata handles the core consultant tasks, policy writing, control mapping, evidence collection, at a fraction of the cost by reading your actual codebase. --- ### What does a SOC 2 audit actually cost? *Keywords: SOC 2 audit cost, SOC 2 compliance cost, SOC 2 certification cost, SOC 2 report cost, cost of SOC 2 audit, SOC 2 cost, SOC 2 price, how much is SOC 2, how much does a SOC 2 audit cost, SOC 2 Type 1 vs Type 2 cost, SOC 2 auditor fees, SOC 2 pricing, ISO 27001 cost, HIPAA compliance cost* *Source: https://screenata.com/resources/answers/what-does-a-soc-2-audit-actually-cost* ## What does a SOC 2 audit cost? Two numbers matter, and most published answers quote only one. The other thing to understand: **the auditor and the preparation are two different bills.** The auditor is a licensed CPA firm that issues the report. Everything else, policies, evidence collection, the control matrix, remediation, is preparation you either buy software plus a consultant for, or have an agent do. ## Cost breakdown by path Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). The auditor fee is identical in all three rows. Screenata does not bundle the audit and does not take referral fees from audit firms, so nothing in this comparison depends on discounting the one line item you cannot skip. What an agent compresses is the middle: the platform, the consultant, and the engineering hours. Seven real quotes from the 2026 market, all for a small B2B SaaS company: The expensive failure is a report your buyer declines to accept, discovered inside their procurement process about three months into a deal cycle. You then pay a second firm to redo it. None of this means small is bad, and a clean opinion from a peer-reviewed boutique carries the same weight with most buyers as one from a large firm. The question to ask about a cheap quote is what makes the price possible, and whether the firm's peer review results are published. For the full version of this analysis see [the bootstrapped founder's guide to SOC 2](/resources/blog/the-bootstrapped-founders-guide-to-soc-2). ## SOC 2 Type 1 vs Type 2 cost This is the most common cost question, and the two are priced differently because they test different things. Most companies get a **Type I first** to unblock a deal, then a **Type II** over the following months. The observation window is where continuous evidence collection matters most: the auditor will sample any date in the period, so evidence has to exist for the whole window, not just at fieldwork. That's the operational work an agent handles on a schedule so you're not reconstructing months of screenshots at the end. ## What drives the auditor fee Auditor pricing depends on: 1. **Scope** — more Trust Services Criteria (adding Availability, Confidentiality, Processing Integrity, or Privacy to Security) means a higher fee. 2. **Company size** — more employees and systems means more testing. 3. **Audit type** — Type II costs more than Type I. 4. **Firm size** — Big 4 firms charge 3–5× what startup-friendly firms charge for the same report. 5. **Readiness** — if your evidence is organized before fieldwork, the engagement is faster and cheaper. 6. **Whether the audit is bundled with your platform** — an unusually low fee usually means the platform introduced the firm and folded the fee into your subscription. That is legal and common, and it is also the thing enterprise reviewers ask about, because the firm attesting to your controls is being paid alongside the vendor whose tooling produced your evidence. 7. **Peer review posture** — any US firm issuing SOC 2 reports should be enrolled in the AICPA Peer Review Program, and you can check that on the AICPA Public Firm File in about a minute. Enrollment is not the same as a completed review, which has three ratings — pass, pass with deficiencies, or fail — and firms choose whether to publish their result. A firm that passed has no reason not to publish, so check three things: enrolled, completed, and published. Treat hesitation as an answer. ## Hidden costs people forget to budget The sticker price is the audit fee. The real budget includes: ## ISO 27001 and HIPAA cost, briefly If you're weighing frameworks: The lever that makes multi-framework affordable is **shared evidence**: SOC 2, ISO 27001, and HIPAA overlap heavily, so one well-collected evidence set can satisfy controls across all three. Screenata maps a single evidence set across frameworks instead of collecting three times. See [Screenata vs Vanta](/compare/vanta) and [the full comparison hub](/compare) for how platforms differ on multi-framework pricing. ## How to minimize cost - Scope to **Security-only** Trust Services Criteria for your first report. - Use a **startup-friendly audit firm**, not Big 4. - Replace the **GRC platform + consultant** with an AI agent that writes policies and collects evidence. - **Prepare evidence before fieldwork** so the engagement is short. - Keep your **system boundary small**. --- ### What does a SOC 2 audit actually involve? *Keywords: SOC 2 audit process, what happens in SOC 2 audit, SOC 2 walkthrough* *Source: https://screenata.com/resources/answers/what-does-a-soc-2-audit-actually-involve* ## What Happens During a SOC 2 Audit? A SOC 2 audit is a structured examination by a licensed CPA firm. The auditor tests whether your security controls are properly designed (Type I) or operating effectively over time (Type II). It is not a penetration test or vulnerability scan, it is a controls-based assessment. ## The Audit Process Step by Step 1. **Scoping**, You and the auditor agree on which Trust Services Criteria are in scope, which systems are included, and the audit period (for Type II) 2. **Control documentation**, You provide a list of your controls mapped to the applicable criteria, often called a controls matrix 3. **Evidence collection**, You gather artifacts proving each control is in place: screenshots, configuration exports, policy documents, access logs, and process records 4. **Walkthrough meetings**, The auditor conducts interviews and walkthroughs to understand how each control works in practice. Expect 2–5 meetings depending on scope 5. **Testing**, The auditor independently tests your controls by reviewing evidence, sampling records, and verifying configurations 6. **Remediation** (if needed), If the auditor finds gaps, you have a chance to fix them before the report is finalized 7. **Report issuance**, The auditor delivers the final SOC 2 report with their opinion ## What Does the Auditor Actually Look At? | Control Area | What Auditors Test | Evidence Examples | |-------------|-------------------|-------------------| | Access control | Who has access, how it is granted and revoked | IAM screenshots, access review records | | Change management | How code and infrastructure changes are tracked | Git logs, PR approvals, deployment records | | Risk assessment | Whether you identify and manage risks | Risk register, risk assessment documents | | Monitoring | How you detect and respond to issues | Alert configurations, incident tickets | | Vendor management | How you evaluate third-party risk | Vendor assessments, contracts | | Encryption | Data protection in transit and at rest | TLS configs, encryption settings | ## How Long Does the Audit Take? The actual audit fieldwork, from first evidence request to report delivery, typically takes 3–6 weeks for Type I and 4–8 weeks for Type II. Preparation before fieldwork is where most time is spent. Screenata handles evidence collection and control documentation before your auditor begins, so fieldwork moves faster. --- ### What does a SOC 2 qualified opinion mean? *Keywords: SOC 2 qualified opinion, SOC 2 exceptions, modified opinion SOC 2* *Source: https://screenata.com/resources/answers/what-does-a-soc-2-qualified-opinion-mean* ## What Is a Qualified Opinion? In a SOC 2 report, the auditor's opinion is the verdict on your controls. There are three possible outcomes: | Opinion Type | What It Means | Impact | |-------------|--------------|--------| | **Unqualified** | Controls are suitably designed and operating effectively | Clean report, this is what you want | | **Qualified** | Controls are generally effective but the auditor found specific exceptions | Usable, but buyers may ask about the exceptions | | **Adverse** | Controls are fundamentally inadequate | Rare and severe | A qualified opinion is the middle ground. Your controls mostly work, but the auditor identified specific areas where they did not meet the criteria. ## What Causes a Qualified Opinion? Common reasons startups receive qualified opinions: 1. **Missing evidence**, A control exists in policy but you cannot produce artifacts proving it was followed 2. **Inconsistent execution**, Your policy requires quarterly access reviews but you only did two in a 12-month period 3. **Configuration gaps**, MFA was required by policy but not enforced on all accounts 4. **Incomplete offboarding**, Former employees retained access after termination 5. **Change management failures**, Code deployed without the required approval process ## Can You Still Use a Report With a Qualified Opinion? Yes. Many organizations share SOC 2 reports with qualified opinions. Buyers read the exceptions and evaluate whether they are material to their risk assessment. A single exception around a minor control is usually acceptable. Multiple exceptions in core security controls raise more concern. ## How to Avoid a Qualified Opinion - **Run a readiness assessment** before engaging your auditor to identify gaps early - **Collect evidence continuously** rather than scrambling at audit time - **Fix issues during the observation period**, auditors note whether problems were detected and remediated - **Test your own controls** by reviewing evidence mid-period Screenata flags control gaps and missing evidence before your auditor begins fieldwork, reducing the risk of exceptions in your final report. --- ### What does "codebase-aware compliance" mean? *Keywords: codebase-aware compliance, code-connected SOC 2, Screenata approach* *Source: https://screenata.com/resources/answers/what-does-codebase-aware-compliance-mean* ## What Is Codebase-Aware Compliance? Codebase-aware compliance is an approach where your compliance tool connects to your source code repositories and cloud accounts to understand how your systems actually work. Instead of you describing your systems to a consultant or filling out template fields, the tool reads your code and configuration directly. ## How It Works | Step | Traditional Approach | Codebase-Aware Approach | |------|---------------------|----------------------| | System discovery | Consultant interviews your team | Tool reads your repos and cloud configs | | Policy writing | Customize templates based on interviews | AI generates policies from code analysis | | Evidence collection | Manual screenshots of each system | Automated capture from connected systems | | Control mapping | Consultant maps controls to criteria | AI maps code patterns to SOC 2 criteria | | Ongoing maintenance | Manual updates when systems change | Tool detects changes and flags policy updates | ## What the Tool Reads When a codebase-aware compliance tool analyzes your systems, it looks at: - **Authentication code:** How users log in, what MFA is enforced, session management - **Authorization logic:** Role-based access control, permission checks on API routes - **Deployment configuration:** CI/CD pipelines, branch protection, deployment targets - **Infrastructure as Code:** Terraform, CloudFormation, or cloud console configurations - **Data handling:** Database schemas, encryption settings, data flow patterns - **Monitoring setup:** Logging configuration, alerting rules, error tracking ## Why It Matters The biggest risk in SOC 2 is a gap between what your policies say and what your systems do. Codebase-aware compliance eliminates this gap by generating policies *from* your systems rather than hoping they match. Traditional: Write policy → hope systems match → auditor tests → find gaps Codebase-aware: Read systems → generate accurate policies → auditor tests → policies match ## Where Screenata Fits Screenata pioneered the codebase-aware compliance approach. It connects to your GitHub repos and cloud accounts, analyzes your technical implementation, and generates SOC 2 policies and evidence that reflect your actual systems, not generic best practices. --- ### What does PHI stand for? *Keywords: what does PHI stand for, PHI stand for, protected health information, PHI in medical terms, example of PHI, what is considered PHI* *Source: https://screenata.com/resources/answers/what-does-phi-stand-for* ## What does PHI stand for? PHI stands for **Protected Health Information**: any health information that identifies an individual, or could reasonably be used to identify them, when it is held or transmitted by a HIPAA covered entity or a business associate. In electronic form it is called **ePHI** and falls under the HIPAA Security Rule. The definition turns on two things together, health information and an identifier, not on either alone. ### The 18 identifiers | | Identifier | |---|---| | 1 | Names | | 2 | Geographic subdivisions smaller than a state | | 3 | All dates related to an individual except year | | 4 | Telephone numbers | | 5 | Fax numbers | | 6 | Email addresses | | 7 | Social Security numbers | | 8 | Medical record numbers | | 9 | Health plan beneficiary numbers | | 10 | Account numbers | | 11 | Certificate or license numbers | | 12 | Vehicle identifiers and serial numbers | | 13 | Device identifiers and serial numbers | | 14 | Web URLs | | 15 | IP addresses | | 16 | Biometric identifiers, including finger and voice prints | | 17 | Full-face photographs and comparable images | | 18 | Any other unique identifying number, characteristic, or code | ## What makes something PHI Three conditions, all required: 1. It is **health information**: physical or mental health, healthcare provision, or payment for healthcare. 2. It **identifies** an individual, through one of the 18 identifiers above. 3. It is held or transmitted by a **covered entity or business associate**. The same data in a consumer fitness app that has no such relationship is generally not PHI. That third condition is the one people miss. HIPAA regulates specific relationships, not health data in the abstract. ## PHI, ePHI, and what changes ePHI is PHI in electronic form. The distinction matters because the **Security Rule applies only to ePHI**, requiring administrative, physical, and technical safeguards. The Privacy Rule applies to PHI in every form, including paper charts and conversations. ## De-identification removes it from scope Two routes, both defined in the Privacy Rule: - **Safe Harbor:** remove all 18 identifiers and have no actual knowledge that the remainder could identify someone. - **Expert determination:** a qualified statistician certifies the re-identification risk is very small and documents the methodology. Removing some identifiers is not de-identification. Data with 15 of 18 removed is still PHI. ## Why this matters for a SaaS company If your product touches PHI on behalf of a covered entity, you are a **business associate** with direct legal obligations, regardless of company size. That means a signed BAA, a documented risk analysis, and implemented safeguards. See [what is a business associate agreement](/resources/answers/what-is-a-business-associate-agreement) and [what is HIPAA compliance and when does a SaaS company need it](/resources/answers/what-is-hipaa-compliance-and-when-does-a-saas-company-need-it). --- ### What evidence does a healthcare SaaS need beyond SOC 2? *Keywords: healthcare compliance, HIPAA plus SOC 2, health tech evidence* *Source: https://screenata.com/resources/answers/what-evidence-does-a-healthcare-saas-need-beyond-soc-2* ## Evidence Beyond SOC 2 | Evidence Type | SOC 2 Covers? | HIPAA Requires? | What to Provide | |---------------|--------------|-----------------|-----------------| | Access controls | Yes | Yes | Already have from SOC 2 | | Encryption | Yes | Yes | Already have from SOC 2 | | Audit logging | Yes | Yes | Already have from SOC 2 | | Business Associate Agreements | No | Yes | Signed BAAs with customers and vendors | | PHI data flow map | No | Yes | Diagram showing where PHI enters, is stored, and exits | | Breach notification process | Partial | Yes (60-day rule) | Specific process for PHI breaches | | Minimum necessary access | No | Yes | Documentation showing PHI access limited to need | | Patient rights procedures | No | Yes | How patients request data access, amendments | | Subprocessor BAAs | Partial | Yes | BAAs with every vendor touching PHI | | Privacy impact assessment | No | Yes | Assessment of privacy risks for PHI handling | ## HIPAA-Specific Evidence Checklist ### Business Associate Agreements - [ ] Template BAA reviewed by healthcare lawyer - [ ] Signed BAA with each healthcare customer - [ ] Signed BAA with each vendor handling PHI (database, hosting, analytics) ### PHI Data Mapping - [ ] Data flow diagram showing PHI lifecycle - [ ] List of all systems storing PHI - [ ] Documentation of PHI encryption methods - [ ] Data retention and disposal policies for PHI ### Privacy Controls - [ ] Minimum necessary access policy - [ ] Patient data access request process - [ ] PHI de-identification procedures (if applicable) - [ ] Marketing use restrictions for PHI ### Breach Response - [ ] HIPAA-specific breach notification procedure (60-day timeline) - [ ] HHS notification process for breaches affecting 500+ individuals - [ ] Media notification process (if required) - [ ] Breach risk assessment methodology ## The Healthcare SaaS Compliance Stack 1. SOC 2 Type II (security foundation) 2. HIPAA compliance (PHI-specific requirements) 3. HITRUST (if selling to large health systems, optional) 4. State privacy laws (California, Texas, New York have additional requirements) --- ### What happens if I miss evidence during my SOC 2 observation period? *Keywords: SOC 2 missing evidence, audit gap, SOC 2 exception handling* *Source: https://screenata.com/resources/answers/what-happens-if-i-miss-evidence-during-my-soc-2-observation-period* ## What Happens When Evidence Is Missing When an auditor can't find evidence for a control during the observation period, they record an exception. An exception means the control didn't operate as described in your policy for that instance. ## Exception Severity | Situation | Impact | |-----------|--------| | Missed one quarterly access review | Minor exception, unlikely to affect opinion | | Skipped access review for the entire period | Major exception, affects opinion | | One hotfix without documentation | Minor exception, normal for startups | | Multiple undocumented direct pushes to main | Pattern of control failure | | Missing incident response for a known incident | Serious, control design questioned | | No evidence for an entire control area | May result in qualified opinion | ## Will It Cause a Qualified Opinion? One or two isolated exceptions typically don't cause a qualified opinion. Auditors use professional judgment: Was this an isolated oversight or a systemic failure? **Isolated exception:** "We missed the Q2 access review because the CTO was on leave, but Q1, Q3, and Q4 reviews were completed." **Systemic failure:** "We wrote a policy saying quarterly access reviews but never conducted any." ## How to Prevent Missing Evidence 1. **Calendar reminders:** Set quarterly reminders for access reviews, vendor reviews, and policy updates 2. **Evidence checklist:** Maintain a list of recurring evidence tasks with due dates 3. **Early collection:** Start collecting evidence from day one of the observation period 4. **Automation:** Use tools that continuously collect evidence rather than relying on manual snapshots ## What to Do If You Already Missed Something - **Don't fabricate evidence.** Backdating screenshots or creating fake review documents is worse than the original gap. - **Document the gap.** Write down what was missed, why, and what you've done to prevent it from happening again. - **Discuss with your auditor.** They may have suggestions for compensating evidence or alternative procedures. - **Fix the process.** Implement the calendar reminders and checklists so it doesn't happen again. --- ### What is a business associate agreement? *Keywords: what is business associate agreement, BAA HIPAA, HIPAA compliant business associate agreement, business associate* *Source: https://screenata.com/resources/answers/what-is-a-business-associate-agreement* ## What is a business associate agreement? A business associate agreement, or BAA, is a **contract HIPAA requires** between a covered entity and any vendor that creates, receives, maintains, or transmits protected health information on its behalf. It obliges the vendor to safeguard PHI, report breaches, bind its own subcontractors to the same terms, and return or destroy PHI when the relationship ends. **Without a signed BAA, disclosing PHI to that vendor is itself a violation**, regardless of whether anything goes wrong. ### What a BAA has to contain | Required term | What it means | |---|---| | Permitted uses and disclosures | What the business associate may do with the PHI, and nothing beyond it | | Safeguards | Implement the Security Rule's administrative, physical, and technical protections | | Breach reporting | Report unauthorised uses and disclosures, within agreed timelines | | Subcontractor flow-down | Any subcontractor touching PHI signs an equivalent agreement | | Access rights | Support the covered entity's obligations for individual access and amendment | | Return or destruction | At termination, return or destroy PHI where feasible | | Termination for breach | The covered entity can terminate for material violation | ## Who is a business associate Anyone handling PHI on behalf of a covered entity: cloud hosting, EHR vendors, billing companies, analytics providers, transcription services, backup providers, and most B2B SaaS serving healthcare. Company size is irrelevant. Intent is irrelevant. If PHI passes through your systems for a covered entity, you are one. Since the **Omnibus Rule (2013)**, business associates carry **direct liability** to HHS rather than only contractual liability to their customer, and must hold BAAs with their own subcontractors. The obligation flows all the way down the chain. ## The practical trap: per-service coverage Most major cloud and SaaS vendors will sign a BAA. What catches teams out is that coverage is usually **per-service, not per-account**. A provider may sign a BAA that covers its core compute and storage while excluding a newer service you happen to be using, and that exclusion is your problem, not theirs. Check two things every time: 1. Will they sign, and on your current plan tier rather than only on enterprise? 2. Is the **specific service** you are using inside the BAA's scope? ## Keeping track of them A BAA register is something an auditor will ask for, and it is the artifact most likely to be out of date. Every vendor touching PHI, the BAA status, the date signed, and the services covered. This is the same problem as vendor management generally, which is why the two usually live together. See [what are the 5 stages of third party management](/resources/answers/what-are-the-5-stages-of-third-party-management) and [BAA status by tool](/hipaa). --- ### What is a chief compliance officer? *Keywords: chief compliance officer meaning, what is a chief compliance officer, CCO role, compliance officer job requirements* *Source: https://screenata.com/resources/answers/what-is-a-chief-compliance-officer* ## What is a chief compliance officer? A chief compliance officer is the **senior executive accountable for the compliance programme**: written policies, training, monitoring and auditing, a reporting channel, investigations, enforcement, and reporting to the board. The role appears by name in the US Federal Sentencing Guidelines' seven elements of an effective compliance programme, which is why regulators and auditors ask who holds it rather than whether the work gets done. ### What the role actually owns | Area | Responsibility | |---|---| | Policies | Written standards exist, are current, and reach the people bound by them | | Training | Delivered to the right people, on a cadence, with records | | Monitoring | Controls are checked rather than assumed | | Reporting channel | A route to raise concerns, usually including an anonymous one | | Investigations | Issues are investigated and corrective action taken | | Enforcement | Disciplinary standards applied consistently | | Board reporting | Periodic reporting to the board or audit committee | Those map one-to-one onto the [seven pillars of compliance](/resources/answers/what-are-the-7-pillars-of-compliance). The role exists to make one person accountable for all seven. ## Independence is the defining feature What distinguishes a real CCO from a title is **authority and access**: enough standing to escalate, and a direct line to the board or audit committee that does not run through the executives whose conduct might be in question. A compliance officer reporting solely to the person they might need to report on is the structural failure regulators look for. ## Do you need one at 30 people? Usually not as a dedicated hire, and that is not what an auditor is testing. They are testing whether **someone is named and has authority**. At a small company that is typically the CTO, COO, or a founder, and it is entirely acceptable provided the assignment is documented and the person actually does the work. The failure mode is nobody owning it. A compliance programme with no named owner produces exactly the pattern audits find: policies nobody has read, training nobody tracked, and access reviews that stopped when the previous owner left. ## CCO and CISO A **CISO** owns security. A **CCO** owns compliance and the ability to demonstrate it. They overlap substantially under SOC 2 and ISO 27001, and at smaller companies one person holds both. If that is you, say so explicitly in the org chart, because an auditor asking for role definitions would rather see one person named twice with clear duties than an ambiguous gap. ## Job requirements, in practice For a first compliance hire at a small company, the useful profile is someone who has been through an audit before, can write clearly, and is comfortable chasing people. Framework certifications matter less than having seen an auditor reject evidence and understanding why. --- ### What is a CSP vs MSP? *Keywords: CSP vs MSP, cloud service provider vs managed service provider, MSP vs MSSP, CSP MSP MSSP difference* *Source: https://screenata.com/resources/answers/what-is-a-csp-vs-msp* ## What is a CSP vs MSP? A **CSP (cloud service provider)** sells cloud infrastructure and platforms that you operate yourself; AWS, Microsoft Azure, and Google Cloud are the three largest. An **MSP (managed service provider)** operates IT on your behalf, often building on or reselling a CSP's services. In short: a CSP gives you the environment, an MSP runs an environment for you. The next term you will hit is **MSSP**, a managed security service provider, which is an MSP specialized in security operations. ## The three terms side by side | | CSP | MSP | MSSP | |---|---|---|---| | What they sell | Cloud infrastructure and platform services (compute, storage, databases) | Operation of your IT: cloud management, help desk, patching, backups | Security operations: monitoring, detection and response, SIEM, often a 24/7 SOC | | Examples | AWS, Microsoft Azure, Google Cloud | Regional IT firms, cloud consultancies, AWS and Azure partner MSPs | Arctic Wolf, Secureworks, security arms of large MSPs | | Your compliance relationship | You inherit controls; their SOC 2 or ISO 27001 covers the infrastructure layer under shared responsibility | Vendor and usually subprocessor; belongs in your vendor register and TPRM reviews | Vendor with privileged security access; highest-scrutiny tier of vendor review | The lines blur in practice. Many MSPs resell CSP capacity, hold administrative access to your CSP accounts, and bundle MSSP-style monitoring. What stays fixed is the relationship: the CSP is a platform you build on, while MSPs and MSSPs are companies acting inside your environment on your behalf. ## The Microsoft "CSP" confusion In Microsoft's ecosystem, CSP also stands for **Cloud Solution Provider**, Microsoft's reseller program. A company enrolled in it resells Microsoft 365 and Azure subscriptions, usually bundled with management services. So a Microsoft "CSP partner" is, in the generic vocabulary, an MSP reselling a CSP. If a vendor introduces itself as "a CSP," ask whether it means it operates a cloud platform or resells Microsoft licensing; the compliance treatment differs completely, because one is an infrastructure provider you inherit controls from and the other is a service vendor you must assess. ## Why the distinction matters for compliance Under the **shared responsibility model**, a CSP is responsible for security of the cloud (physical data centers, hardware, the hypervisor) and you are responsible for security in the cloud (your configurations, access, data). In a SOC 2 or ISO 27001 audit, you inherit the CSP's infrastructure-layer controls by relying on its own audit reports; the major CSPs publish SOC 2 reports for exactly this purpose. You do not audit AWS; you collect its report and carry your side of the responsibility split. An MSP sits on the other side of the line. It works inside your responsibility zone, often with administrator access, which makes it a vendor and usually a subprocessor of your customer data. That places it in your vendor register, subject to your third-party risk management process: collect its SOC 2 or equivalent, review it at least once a year, and bind it with a contract and, where personal data is involved, a data processing agreement. Your own SOC 2 report will then treat the MSP as a subservice organization, disclosed under the carve-out or inclusive method. The practical summary: a CSP reduces your control surface because you inherit the layers it operates, while an MSP expands your vendor risk surface because a third party now acts with your privileges. Both can be the right choice; they just land in different sections of your compliance program. For how the relationship looks from the MSP's side, see [how an MSP should manage compliance evidence for multiple clients](/resources/answers/how-should-an-msp-manage-compliance-evidence-for-multiple-clients). --- ### What is a GRC platform and do startups need one for SOC 2? *Keywords: GRC platform, compliance platform, do I need Vanta* *Source: https://screenata.com/resources/answers/what-is-a-grc-platform-and-do-startups-need-one-for-soc-2* ## What Is a GRC Platform? A GRC platform is software that centralizes your compliance program, policies, evidence, control monitoring, and audit management, in one place. For SOC 2, platforms like Drata, Vanta, and Secureframe connect to your cloud infrastructure, pull configuration data, and flag gaps against Trust Services Criteria. They handle the compliance *dashboard*. They don't handle the compliance *work*. ## What GRC Platforms Actually Do | Capability | What It Covers | What It Doesn't | |------------|---------------|-----------------| | Infrastructure monitoring | AWS, GCP, Azure config checks | Application-level controls | | Policy storage | Host your policies in one place | Write policies that match your stack | | Employee onboarding | Track security training, background checks | Define what training you need | | Vendor management | Track vendor SOC 2 reports | Assess actual vendor risk | | Evidence collection | Pull cloud API data | Capture screenshots, app-level proof | ## Do Startups Need One? ## Where Screenata Takes a Different Approach --- ### What is a risk register? *Keywords: risk register, risk registration, risk register template, inherent vs residual risk* *Source: https://screenata.com/resources/answers/what-is-a-risk-register* ## What is a risk register? A risk register is the **log of risks an organisation has identified**, each carrying an owner, an assessment of likelihood and impact, a treatment decision, and a residual score after treatment. It is the central artifact of a risk management programme and usually the first thing an auditor asks for under SOC 2 CC3 or ISO 27001 clause 6.1. Its purpose is to show that risks were identified, decided on, and owned, not merely listed. ### The fields that matter | Field | Why it is there | |---|---| | Risk description | What could go wrong, stated specifically enough to act on | | Asset or objective affected | What it threatens | | Owner | A named person, not a team | | Inherent likelihood and impact | Exposure before controls | | Treatment | Avoid, reduce, transfer, accept, or share | | Controls applied | What actually mitigates it | | Residual likelihood and impact | What remains after treatment | | Review date | When it was last looked at | ## The failure auditors find most often **Blank inherent and residual scores.** A register with well-written risks, assigned owners, and sensible treatment plans, and no numbers, is extremely common in young programmes. It fails because without both scores you cannot show that treatment changed anything, and the whole point of recording residual risk is to evidence that the controls did something. The second most common: **acceptance with no record of who accepted it.** Accepting a risk is a legitimate treatment and auditors see it constantly. What fails is an undocumented acceptance, because from the outside it is indistinguishable from having missed the risk. ## Scoring without overengineering A 5x5 likelihood-by-impact matrix is the common default and is entirely sufficient. What matters is that the scale is **defined somewhere** and applied consistently, not that it is sophisticated. An auditor will ask what a 4 means. "High" is not an answer; "more likely than not within 12 months" is. Quantitative methods exist and are rarely worth it below a certain size. A qualitative matrix, applied consistently and reviewed on schedule, passes every audit a small company will face. ## What the register connects to - **Treatments** come from the five options: avoid, reduce, transfer, accept, share. See [what are the five risk mitigation strategies](/resources/answers/what-are-the-five-risk-mitigation-strategies). - **Controls** implemented as treatment are the same controls your framework tests. - **Vendors** are a risk category of their own, usually tracked in a separate register. See [what are the 5 stages of third party management](/resources/answers/what-are-the-5-stages-of-third-party-management). ## Where frameworks require it | Framework | Requirement | |---|---| | SOC 2 | CC3 series, risk identification and analysis | | ISO 27001 | Clause 6.1, plus a documented risk assessment methodology | | HIPAA | Security Rule risk analysis, the most cited enforcement gap | | NIST 800-53 | RA family | ISO is the strictest: it wants the **methodology** documented, not just the output, so that the assessment is repeatable by someone else. --- ### What is an SOC 2 bridge letter and when do you need one? *Keywords: SOC 2 bridge letter, gap letter, SOC 2 coverage gap* *Source: https://screenata.com/resources/answers/what-is-a-soc-2-bridge-letter-and-when-do-you-need-one* ## What Is a SOC 2 Bridge Letter? A bridge letter (also called a gap letter) is a written statement from your management that covers the time between the end of your most recent SOC 2 report period and the present date. If a prospect requests your report in March but your audit period ended in December, the bridge letter fills that 3-month gap by asserting that controls continued to operate without material changes. ## When Do You Need One? | Scenario | Bridge Letter Needed? | Why | |----------|----------------------|-----| | Prospect requests report and audit period ended 2+ months ago | Yes | Buyers want assurance controls are still in place | | Between audit periods with renewal in progress | Yes | Old report is aging while new one is in fieldwork | | Type I report is 4+ months old | Yes | Point-in-time snapshot is getting stale | | Report period ended last week | No | Gap is negligible | | Current Type II with period ending within 3 months | Usually no | Most buyers accept this as current | ## What Goes in a Bridge Letter? A bridge letter typically includes: 1. **Reference to the SOC 2 report**, report type, period covered, auditor name 2. **Assertion of no material changes**, confirmation that your control environment has not changed significantly 3. **Description of any changes**, if you did make changes, disclose them and explain impact 4. **Date and signature**, signed by an authorized executive ## Is a Bridge Letter a Substitute for a Current Report? No. A bridge letter is a stopgap, not a replacement. It is your management's assertion, not an auditor's opinion. Most buyers accept bridge letters for gaps of 3–6 months. Beyond 6 months, buyers will push for a new audit. The best way to minimize bridge letter needs is to time your audit periods so coverage stays current. Screenata helps maintain continuous evidence collection so your next audit period starts immediately after the prior one ends. --- ### What is a SOC 2 information security policy? *Keywords: SOC 2 security policy, information security policy, SOC 2 policy example* *Source: https://screenata.com/resources/answers/what-is-a-soc-2-information-security-policy* ## What Is an Information Security Policy? An information security policy is the parent document for your entire security program. It establishes the rules, responsibilities, and expectations for how your organization handles sensitive data. For SOC 2, it maps to CC1.1 through CC1.5, the "Control Environment" criteria. Think of it as the constitution for your security program. Other policies (access control, change management, incident response) operate underneath it. ## What It Should Include | Section | What to Cover | |---------|---------------| | Purpose and scope | What the policy covers, who it applies to | | Roles and responsibilities | Who owns security decisions (CEO, CTO, engineering leads) | | Data classification | How you categorize data (public, internal, confidential, restricted) | | Acceptable use | Rules for employee device and system usage | | Security awareness | Training requirements and frequency | | Policy review schedule | How often policies are updated (annually minimum) | | Enforcement | Consequences for policy violations | ## Common Mistakes for Startups **Writing it like a Fortune 500 company.** You don't need a 30-page policy. A 3-5 page document that accurately describes your 10-person startup's security approach is better than a lengthy document that doesn't match reality. **Copying a template verbatim.** Templates reference controls and processes you may not have. If the template mentions a "Security Operations Center" and you're five engineers, that's a problem. **Forgetting to name names.** Auditors want to see specific roles. "The CTO is responsible for security architecture" is better than "Management is responsible for security." ## How to Write One Start with what's true about your company. Who makes security decisions? How do you handle sensitive data? What tools do you use? Document that reality, then identify gaps to fill before your audit. Screenata automates this by reading your codebase and generating a security policy that reflects your actual organization structure and tech stack. --- ### What is a SOC 2 observation period? *Keywords: SOC 2 observation period, Type 2 audit window, SOC 2 timeline* *Source: https://screenata.com/resources/answers/what-is-a-soc-2-observation-period* ## What Is the Observation Period? The observation period is the window of time that a SOC 2 Type II audit covers. During this period, your controls must be in place and operating effectively. The auditor tests evidence from across the entire window to confirm your controls worked consistently. This is the key difference between Type I and Type II. Type I checks controls at a single point in time. Type II checks controls across the observation period. ## How Long Is the Observation Period? | Duration | When It Is Used | Trade-offs | |----------|----------------|------------| | 3 months | Minimum acceptable; common for first Type II | Faster, but some buyers prefer 6+ months | | 6 months | Most common for initial Type II audits | Good balance of speed and credibility | | 9 months | Less common; timing alignment with fiscal year | Longer evidence collection burden | | 12 months | Standard for mature organizations | Maximum coverage, longest wait | Most startups doing their first Type II choose a 3- or 6-month observation period. ## What Happens During the Observation Period? You are expected to: 1. **Operate controls consistently**, If your policy says quarterly access reviews, you need to actually do them and have evidence 2. **Collect evidence continuously**, Screenshots, logs, and records must cover the entire window 3. **Respond to incidents**, Security events need documented incident response 4. **Maintain documentation**, Policy changes, system changes, and personnel changes should be tracked ## When Does It Start? There is no formal start event. The observation period begins when your controls are in place and operating. If you complete a Type I on March 1, your Type II observation can begin March 2. ## What If Something Goes Wrong? A control failure during the observation period does not automatically ruin your audit. Auditors expect occasional issues, what matters is how you detect and respond. If your monitoring catches a violation and your incident response handles it properly, that is evidence of a working control. Screenata collects evidence continuously throughout the observation period so nothing falls through the cracks. --- ### What is a SOC 2 readiness assessment? *Keywords: SOC 2 readiness, readiness assessment, pre-audit SOC 2* *Source: https://screenata.com/resources/answers/what-is-a-soc-2-readiness-assessment* ## What Is a SOC 2 Readiness Assessment? A readiness assessment is a dry run of your SOC 2 audit. It evaluates your existing controls, policies, and evidence against the Trust Services Criteria you plan to include. The goal is to find gaps before the auditor does, so you can fix them on your timeline rather than scrambling during fieldwork. Readiness assessments are not required, but they significantly reduce the risk of a qualified opinion or delays during the actual audit. ## What Does a Readiness Assessment Cover? | Assessment Area | What Is Evaluated | Common Gaps Found | |----------------|-----------------|-------------------| | Policies | Do written policies exist for security, access, change management, incident response? | Missing policies or policies not reviewed in 12+ months | | Access controls | Are access reviews performed? Is MFA enforced? | No formal access review process, shared credentials | | Change management | Are code changes tracked and approved before deployment? | Deployments without PR reviews | | Risk management | Is there a risk assessment process? | No formal risk register | | Vendor management | Are third-party vendors evaluated for security? | No vendor assessment process | | Monitoring | Are security events monitored? Are incidents tracked? | No centralized logging or incident response | | Evidence | Can you produce artifacts for each control? | Evidence exists but is not organized | ## Who Performs a Readiness Assessment? You have three options: ## How Long Does It Take? A readiness assessment typically takes 1–3 weeks depending on the size of your organization and the state of your controls. The output is a gap report with prioritized findings. Screenata runs an automated readiness assessment as part of onboarding, identifying control gaps and generating a remediation plan in days instead of weeks. --- ### What is a system description for SOC 2? *Keywords: SOC 2 system description, SOC 2 section 3, system description example* *Source: https://screenata.com/resources/answers/what-is-a-system-description-for-soc-2* ## What Is a System Description? The system description is Section 3 of your SOC 2 report. It's a narrative document that explains what your company does, how your systems work, where data flows, and what controls are in place. Auditors read it to understand the boundaries of the audit, what's included and what's not. It's written by your organization (not the auditor), though auditors review it for accuracy and may suggest edits. ## What a System Description Covers | Section | What to Describe | |---------|-----------------| | Company overview | What your company does, who your customers are | | Services in scope | Which products or services the audit covers | | System boundaries | Infrastructure, software, people, data included in scope | | Infrastructure | Cloud providers, hosting, networking, deployment | | Software | Application architecture, third-party services, integrations | | People | Roles and responsibilities related to security | | Data | Types of data processed, data flows, storage locations | | Controls | Summary of key controls mapped to Trust Services Criteria | ## Why It Matters If your system description says you use AWS but you've recently migrated to Vercel, the auditor will test against what's written. Mismatches between the description and reality create findings. Accuracy is more important than length. ## Tips for Startups - **Be specific about your stack.** "Deployed on Vercel with PostgreSQL on Supabase" is better than "deployed on cloud infrastructure." - **Define what's out of scope.** If your marketing site runs on a separate platform, say so explicitly. - **Include data flow diagrams.** Even a simple diagram showing how customer data enters, is processed, and is stored helps auditors and speeds up the audit. - **Update it.** If you change cloud providers or add new services between writing the description and starting the audit, update the document. --- ### What is a trust center? *Keywords: what is a trust center, trust center page, security trust center, trust portal SOC 2* *Source: https://screenata.com/resources/answers/what-is-a-trust-center* ## What is a trust center? A trust center is a **public web page where a software vendor publishes its security and compliance posture** for prospective customers. It usually lives at a subdomain such as trust.yourcompany.com and shows the frameworks the company holds, the controls it runs, its subprocessors, and its policies. Sensitive documents, such as a SOC 2 report, sit behind a request gate. The page exists to answer a buyer's security team before they send the email or the questionnaire. ## What goes on a trust center Most trust centers split content into what anyone can read and what a buyer has to request. | Content | Public or gated | Why buyers look for it | |---|---|---| | Frameworks held (SOC 2, ISO 27001, HIPAA) | Public | First screen of every vendor review | | Control summary by area (access, encryption, monitoring) | Public | Lets the reviewer skip half the questionnaire | | Subprocessor list | Public | Required reading for GDPR and DPA reviews | | Security policies or policy summaries | Public or gated | Evidence the program is written down | | SOC 2 report | Gated, usually behind an NDA | Restricted-use document under AICPA standards | | Penetration test summary or letter | Gated | Proof of independent testing | | Changelog of security updates | Public | Shows the page is maintained | The gate matters as much as the content. Each gated download should create an access record: who requested it, who approved it, and when. That record is what you show a customer or an auditor who asks where the report went. ## Why a trust center shortens security reviews Enterprise security reviews start with the same few requests: the SOC 2 report, the subprocessor list, and a questionnaire. When those are already published and requestable, the reviewer starts from the page instead of from an email thread, and the questionnaire that follows is shorter because the obvious questions are answered. Trust pages are still uncommon among smaller vendors. Of 494 B2B SaaS companies Screenata looked at, 101 had a trust page. For a startup in an enterprise deal, a maintained trust center is one of the cheaper ways to look like the more prepared vendor. ## How a trust center stays accurate A trust center goes stale the same way a policy does: someone publishes it once and the controls change underneath it. The durable approach is to publish from the compliance program itself, so control status, framework status, and the subprocessor list update when the underlying records do. --- ### What is a vCISO and do I need one for SOC 2? *Keywords: vCISO, virtual CISO, do I need a vCISO, SOC 2 consultant* *Source: https://screenata.com/resources/answers/what-is-a-vciso-and-do-i-need-one-for-soc-2* ## What Is a vCISO? A vCISO is a fractional security leader, typically a consultant with CISO experience who works with multiple companies on a part-time basis. They provide the compliance expertise startups lack internally: writing security policies, designing controls, preparing for audits, and serving as the security point of contact for your organization. ## What Does a vCISO Do for SOC 2? | Task | What They Do | Time Required | |------|-------------|---------------| | Gap assessment | Review your infrastructure against SOC 2 requirements | 10–20 hours | | Policy writing | Write 4–7 security policies customized to your stack | 20–40 hours | | Control mapping | Map your controls to Trust Services Criteria | 5–10 hours | | Evidence guidance | Tell you what evidence to collect and how | 10–20 hours | | Auditor liaison | Communicate with the audit firm on your behalf | 5–15 hours | | Remediation support | Help fix gaps found during readiness or audit | 10–30 hours | ## How Much Does a vCISO Cost? ## Do You Actually Need One? You'll likely want a vCISO if: - You have no one internally who understands compliance frameworks and want a security leader to own the program - You are pursuing multiple frameworks simultaneously - Your audit scope is large (100+ employees, multiple systems) You can probably reach a first audit without paying for a full vCISO engagement if: - Your team is under 50 people - You are pursuing SOC 2 Security-only - You're willing to use AI tools that automate the operational work, policy drafting, control mapping, and evidence collection ## The AI Angle The operational side of the vCISO role, analyzing infrastructure, writing policies, mapping controls, and collecting evidence, is repeatable and automatable. Screenata performs that layer automatically, so a small team can reach audit-ready without buying those hours by hand. It also works the other way: vCISO firms run Screenata across their clients to absorb the operational grind, freeing their people for the judgment work and letting them take on more clients at the same headcount. See [Screenata for vCISO firms](/for-vcisos). --- ### What is an AI compliance officer? *Keywords: AI compliance officer, AI for SOC 2, AI audit prep* *Source: https://screenata.com/resources/answers/what-is-an-ai-compliance-officer* ## What Is an AI Compliance Officer? ## AI Compliance Officer vs. GRC Platform vs. Consultant ## What Makes It Different from ChatGPT? You could paste SOC 2 questions into ChatGPT, but it doesn't know your systems. It generates generic answers based on training data. An AI compliance officer connects to your actual codebase and cloud accounts, it knows you use NextAuth for authentication, Vercel for deployment, and Supabase for your database. Policies it writes reference those specific systems. ## Where Screenata Fits Screenata is an AI compliance officer built specifically for startups pursuing SOC 2. It reads your GitHub repos and cloud infrastructure, writes policies that reference your actual systems, collects application-level evidence automatically, and gets you audit-ready in weeks rather than months. --- ### What is an example of a third-party vendor? *Keywords: example of a third party vendor, third party service examples, what is a fourth party vendor, third party vendor risk* *Source: https://screenata.com/resources/answers/what-is-an-example-of-a-third-party-vendor* ## What is an example of a third-party vendor? A third-party vendor is **any outside company that provides goods or services to your organization under a contract**. For a SaaS company the common examples are its cloud provider (AWS, Google Cloud, Azure), payment processor (Stripe), productivity and messaging tools (Google Workspace, Slack), payroll provider (Gusto, Deel), and CRM or support platform (HubSpot, Zendesk). A **fourth party** is your vendor's vendor, such as the cloud host behind your CRM. ## Third-party vendor examples by category | Category | Examples | Typical data access | Risk tier | |---|---|---|---| | Cloud infrastructure | AWS, Google Cloud, Azure, Cloudflare | Hosts production and customer data | High | | Code and deployment | GitHub, Vercel, Datadog | Source code, secrets, logs | High | | Identity | Okta, Google Workspace, Microsoft Entra ID | Controls access to everything else | High | | Payments | Stripe, Braintree | Cardholder and billing data | High | | Customer communication | Zendesk, Intercom, SendGrid | Customer names, emails, message content | Medium | | HR and payroll | Gusto, Deel, Rippling | Employee personal and financial data | Medium | | Sales and marketing | HubSpot, Salesforce, LinkedIn Ads | Prospect contact data | Medium to low | | Professional services | Law firm, auditor, penetration tester | Varies; often confidential documents | Varies | | Office and facilities | Coworking space, hardware reseller | Physical access, devices | Low | Tier each vendor by what it can reach. A free analytics script on a login page can carry more risk than an expensive consulting contract. ## Third, fourth, and nth parties | Party | Relationship | How you manage the risk | |---|---|---| | Third party | Contracts directly with you | Security review, contract terms, periodic reassessment | | Fourth party | Contracts with your vendor | Your vendor's subprocessor list and its SOC 2 subservice organization disclosures | | Nth party | Further down the chain | Concentration analysis, such as how many critical vendors depend on one cloud region | A SOC 2 report handles fourth parties explicitly. The system description names subservice organizations and states whether their controls are included (the inclusive method) or carved out (the carve-out method). When a vendor carves out its cloud host, you need that host's own report as well. ## What compliance frameworks require for vendors SOC 2 criterion CC9.2 asks you to assess and manage risk from vendors and business partners. ISO 27001 Annex A covers supplier relationships in its organizational controls. HIPAA requires a business associate agreement with every vendor that creates, receives, maintains, or transmits PHI for you. In practice, an auditor asks for the same four things under each framework: a complete vendor inventory, a risk rating per vendor, evidence of review for the high-risk ones (usually their SOC 2 report or a questionnaire), and signed contracts or BAAs. The most common gap is the inventory itself, because vendors get added by engineers through a package, an API key, or a free-tier signup, without anyone recording it. For the lifecycle around that inventory, see [the five stages of third-party management](/resources/answers/what-are-the-5-stages-of-third-party-management). --- ### What is application-level evidence for SOC 2? *Keywords: application-level controls, SOC 2 application evidence, app-level SOC 2* *Source: https://screenata.com/resources/answers/what-is-application-level-evidence-for-soc-2* ## What Is Application-Level Evidence? Application-level evidence proves that security controls operate within your software product, not just in your cloud infrastructure. While GRC platforms like Drata and Vanta monitor your AWS or GCP configurations, they can't see inside your application to verify that your role-based access control works, that your data export controls function, or that your feature flags follow an approval process. ## Infrastructure Evidence vs. Application Evidence | Layer | Evidence Example | Who Captures It | |-------|-----------------|-----------------| | Infrastructure | AWS S3 encryption is enabled | GRC platforms (automated) | | Infrastructure | IAM policies restrict admin access | GRC platforms (automated) | | Application | Your app enforces role-based permissions on API endpoints | Manual screenshots or Screenata | | Application | Admin-only features are gated by role checks in code | Manual screenshots or Screenata | | Application | Data export follows audit trail logging | Manual screenshots or Screenata | | Application | Feature flags require approval before production activation | Manual screenshots or Screenata | ## Why Application-Level Evidence Matters Most SOC 2 findings happen at the application layer, the gap between what your cloud is configured to do and what your application actually enforces. Your AWS IAM policy might restrict database access to your app server, but if your application doesn't enforce permissions on who can read what data, that's a control gap. Auditors increasingly ask about application-level controls because they know cloud configuration alone doesn't tell the full story. ## How to Collect It Traditionally, application-level evidence means manual screenshots, logging into your app, navigating to settings pages, and capturing what's there. For a typical SOC 2 audit, you might need 30-50 application-level screenshots. Screenata automates this process. It records your application workflows, captures evidence with full traceability, and generates audit-ready documentation that includes timestamps, user context, and the specific control being demonstrated. --- ### What is CC6.1 in SOC 2 and what evidence does it require? *Keywords: SOC 2 CC6.1, access controls evidence, RBAC evidence* *Source: https://screenata.com/resources/answers/what-is-cc6-1-in-soc-2-and-what-evidence-does-it-require* ## What Is CC6.1? CC6.1 falls under the Security category of Trust Services Criteria. It states that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." In plain language: you must control who can access your systems and data. It's almost always the most evidence-heavy criterion in a SOC 2 audit. ## Evidence Auditors Need for CC6.1 | Control Area | Evidence Required | |-------------|------------------| | Authentication | Screenshot of SSO/MFA settings showing enforcement | | Role-based access | User list showing role assignments, permission matrix | | Least privilege | Evidence that users only have access they need for their job | | Access provisioning | Ticket or record of access request and approval for a new hire | | Access revocation | Evidence showing access removed for terminated employees | | Access reviews | Quarterly review documentation showing who was reviewed and outcomes | | Shared accounts | Evidence that shared credentials are prohibited or exception-documented | ## How Startups Can Satisfy CC6.1 1. **Use SSO with MFA.** Google Workspace or Okta with enforced MFA covers your identity layer. 2. **Implement basic RBAC.** Even two roles (admin vs. member) in GitHub and your cloud provider demonstrates least privilege. 3. **Document onboarding/offboarding.** Create a checklist of systems accessed, who grants/revokes, and keep records. 4. **Run quarterly access reviews.** Export user lists from each system, confirm each user still needs access, document the review with date and reviewer. 5. **Screenshot everything.** Capture MFA settings, role assignments, and branch protection rules with timestamps. ## Common Findings - MFA available but not enforced (users can opt out) - Former employees still have active accounts - All engineers have admin access with no role differentiation - No documented access review within the audit period --- ### What is CC8.1 in SOC 2 and how do you prove change management? *Keywords: SOC 2 CC8.1, change management evidence, SOC 2 change approval* *Source: https://screenata.com/resources/answers/what-is-cc8-1-in-soc-2-and-how-do-you-prove-change-management* ## What Is CC8.1? CC8.1 requires that "the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives." Translation: don't push untested, unapproved code to production. For SaaS startups using GitHub, you're probably already doing most of this. You just need to prove it. ## Evidence for CC8.1 | Control | Evidence | |---------|----------| | Change authorization | GitHub PR with description of the change | | Peer review | PR showing at least one approving review | | Testing | CI pipeline results (GitHub Actions, Vercel preview) | | Approval | Reviewer approval timestamp on the PR | | Deployment | Deployment log showing the merge triggered a production deploy | | Branch protection | Screenshot of branch protection settings on main | ## How to Demonstrate CC8.1 ### Configuration Evidence (Type I and II) - Screenshot of GitHub branch protection rules (required reviewers, status checks) - Screenshot of CI/CD pipeline configuration (GitHub Actions, Vercel) - Change management policy document ### Population Evidence (Type II) - Auditor samples 20-25 PRs from the audit period - Each PR should show: description, reviewer approval, passing CI checks, merge to main - No direct commits to main without a PR ## Handling Emergency Changes Auditors understand that hotfixes happen. Document your emergency change process: 1. Deploy the hotfix directly 2. Create a post-deployment PR within 24 hours 3. Document why the standard process was bypassed 4. Get retroactive review Having a few documented emergency changes is fine. Having undocumented direct pushes to main is not. ## Common Findings - Branch protection disabled or set to "allow admins to bypass" - PRs merged without reviewer approval - No CI pipeline running tests before merge - Emergency changes without post-deployment documentation --- ### What is compliance evidence automation? *Keywords: compliance evidence automation, automated audit evidence, evidence automation* *Source: https://screenata.com/resources/answers/what-is-compliance-evidence-automation* ## What Is Evidence Automation? Evidence automation replaces the manual process of collecting SOC 2 (and other framework) evidence with software that continuously captures and organizes proof of control effectiveness. Instead of logging into 15 admin consoles and taking screenshots before each audit, automated tools pull evidence on a schedule or in real time. ## Levels of Automation | Level | Description | Examples | Coverage | |-------|-------------|----------|----------| | Manual | Screenshots, spreadsheets, Google Drive | Human effort | 100% (but slow and error-prone) | | API monitoring | Pull configuration data from cloud APIs | Drata, Vanta | ~50% of evidence (infrastructure only) | | API + application | Monitor infrastructure and capture app-level evidence | Screenata | ~80% of evidence | | Continuous | Real-time monitoring with automated alerting | Future state | ~90% of evidence | ## What Gets Automated | Evidence Type | Automation Method | |---------------|------------------| | Cloud configurations | API checks against AWS, GCP, Azure | | MFA enforcement | Identity provider API | | User access lists | SSO/IdP user exports | | Code change approvals | GitHub PR API | | Deployment records | CI/CD platform API | | Device compliance | MDM integration | | Application controls | AI-captured screenshots and workflows | | Encryption settings | Database and storage API checks | ## Benefits 1. **Time savings:** 40-80 hours of manual evidence collection reduced to 5-10 hours 2. **Consistency:** Same evidence quality every time, no missed screenshots 3. **Continuous readiness:** Always audit-ready, not scrambling before the audit 4. **Cross-framework reuse:** Automated evidence maps to multiple frameworks simultaneously 5. **Reduced audit cost:** Auditors spend less time requesting additional evidence ## Where Screenata Fits Screenata automates compliance evidence at the application level, the layer that traditional GRC platforms miss. It captures screenshots, configuration states, and control validations from your actual application interfaces, complementing the infrastructure monitoring that API-based tools handle. --- ### What is CSA and CCM? *Keywords: what is CSA CCM, Cloud Controls Matrix, CSA STAR certification, CAIQ questionnaire* *Source: https://screenata.com/resources/answers/what-is-csa-ccm* ## What is CSA and CCM? **CSA is the Cloud Security Alliance**, a nonprofit organization that publishes security best practices for cloud computing. **CCM is its Cloud Controls Matrix**, a control framework written specifically for cloud services. Version 4.1 of the CCM contains 207 controls across 17 domains and maps to ISO 27001, NIST SP 800-53, PCI DSS, and other standards. CSA also runs the STAR program, which lets cloud providers publish self-assessments or third-party validation against the CCM. ## What the Cloud Controls Matrix covers The CCM's 17 domains cover the ground of a general security framework, with more attention to how responsibility splits between a cloud provider and its customer. | Area | Domains include | What is cloud-specific | |---|---|---| | Governance and risk | Governance, Risk and Compliance; Audit and Assurance | Shared responsibility defined per control | | Identity and access | Identity and Access Management | Customer versus provider administrative access | | Data | Data Security and Privacy Lifecycle Management; Cryptography, Encryption and Key Management | Data location, tenant separation, customer-managed keys | | Infrastructure | Infrastructure and Virtualization Security; Datacenter Security | Hypervisor and multi-tenant isolation | | Operations | Logging and Monitoring; Threat and Vulnerability Management; Change Control and Configuration Management | Visibility customers can get into provider operations | | Supply chain | Supply Chain Management, Transparency, and Accountability | Controls on the provider's own cloud subprocessors | | Resilience | Business Continuity Management and Operational Resilience; Security Incident Management, E-Discovery, and Cloud Forensics | Provider versus customer recovery obligations | Since version 4, the CCM includes shared security responsibility guidance that assigns each control to the cloud provider, the customer, or both. That split is the main thing the CCM adds over a general catalog such as ISO 27001 Annex A. ## CSA STAR levels | Level | What it is | Who performs it | |---|---|---| | Level 1: Self-Assessment | Completed CAIQ questionnaire published in the STAR Registry | The provider itself | | Level 2: Certification | ISO 27001 certification audit extended to cover the CCM | An accredited certification body | | Level 2: Attestation | SOC 2 examination extended to cover the CCM criteria | A licensed CPA firm | The STAR Registry is public, so a buyer can look up a provider's submission without asking for it. Level 1 costs nothing to publish, which is why many SaaS vendors use it to answer cloud-specific questionnaires before pursuing a formal audit. ## Where the CCM fits for a SaaS company For most B2B SaaS companies, the CCM is a complement to SOC 2 or ISO 27001 rather than a replacement. Buyers ask for those two by name. The CCM becomes useful in two situations: when a customer sends the CAIQ as its security questionnaire, and when a company already running SOC 2 or ISO 27001 wants STAR Level 2 by adding the CCM to an existing audit instead of starting a new one. Because the CCM maps to both, much of the evidence is already collected. For how the underlying frameworks overlap, see [the controls shared by SOC 2, ISO 27001, and HIPAA](/resources/answers/what-controls-overlap-between-soc-2-iso-27001-and-hipaa). --- ### What is GRC? *Keywords: what is GRC, GRC meaning, governance risk and compliance, GRC tooling, GRC software* *Source: https://screenata.com/resources/answers/what-is-grc* ## What is GRC? GRC stands for **Governance, Risk, and Compliance**: three disciplines managed as one rather than in separate silos. Governance sets direction, accountability, and policy. Risk management identifies, assesses, and treats what could go wrong. Compliance meets obligations imposed from outside. The term describes both an operating approach and a software category, and treating those as the same thing is the most common mistake when evaluating tools. ### The three letters | Letter | Answers | Typical artifact | |---|---|---| | **Governance** | Who decides, and on what authority? | Policies, roles, board reporting, delegation of authority | | **Risk** | What could go wrong, and what are we doing about it? | Risk register with owners, scores, and treatments | | **Compliance** | What are we obliged to do, and can we prove it? | Control matrix, evidence, audit reports, certificates | The argument for managing them together is that they share inputs. A risk assessment drives which controls you implement, controls produce compliance evidence, and governance decides who owns the result. Run separately, the same work gets done three times and the answers disagree. ## GRC the practice, and GRC the software category These are different things sold to different buyers. **Enterprise GRC platforms** (Archer, MetricStream, ServiceNow GRC, LogicGate, Riskonnect) manage enterprise risk registers, policy lifecycle, audit workflow, and regulatory change across large organisations with a staffed risk function. Implementation is a project measured in months. **Compliance automation platforms** (Vanta, Drata, Secureframe, Sprinto, Scrut) connect to your cloud and identity systems, monitor controls against a framework like SOC 2, and surface what needs evidence. The buyer is a company pursuing a certification. **Agent-first tools** (Screenata) perform the work rather than tracking it: generating policies from attested operations, running the tests, chasing attestations, filing evidence. A 20-person SaaS company that needs SOC 2 to close a deal has a narrow problem. Buying an enterprise GRC suite for it is the expensive version of the mistake, and buying nothing and doing it in a spreadsheet is the cheap version. ## The GRC Capability Model The most-cited structural model is OCEG's, which describes four components: **Learn, Align, Perform, Review**. It is a cycle rather than a sequence, and the loop back from Review to Learn is what stops a program rediscovering the same gaps each year. See [what are the 4 components of GRC](/resources/answers/what-are-the-4-components-of-grc). ## Where most programs actually fail Not in governance, which is usually documented. In **Perform and Review**: controls that exist on paper and never operated, and findings that never fed back. An auditor can only test evidence, so a control with no artifact behind it is an assertion regardless of how well the governance around it is written. --- ### What is HIPAA compliance and when does a SaaS company need it? *Keywords: HIPAA for SaaS, HIPAA compliance, when HIPAA required* *Source: https://screenata.com/resources/answers/what-is-hipaa-compliance-and-when-does-a-saas-company-need-it* ## What is HIPAA compliance and when does a SaaS company need it? HIPAA compliance means meeting the Privacy, Security, and Breach Notification Rules that govern protected health information. A SaaS company needs it when it creates, receives, maintains, or transmits PHI on behalf of a covered entity, which makes it a business associate with direct legal obligations. Company size is irrelevant, and so is whether you intended to handle health data. ### When it applies to you You need HIPAA if your software handles Protected Health Information (PHI). Specifically: | Your Customer | Data You Handle | HIPAA Required? | |---------------|----------------|-----------------| | Hospital or clinic | Patient records, appointment data | Yes | | Health insurance company | Claims data, member information | Yes | | Healthcare software vendor | PHI passed through your system | Yes (business associate) | | Wellness app (no PHI) | Step counts, general health tips | No | | Non-healthcare company | Employee data (not PHI) | No | ## What HIPAA Requires | Requirement | What It Means | |-------------|---------------| | Business Associate Agreement (BAA) | Legal contract with healthcare customers defining your PHI responsibilities | | Administrative safeguards | Policies, training, risk assessment for PHI handling | | Physical safeguards | Physical access controls for systems with PHI | | Technical safeguards | Encryption, access controls, audit logging for PHI | | Breach notification | 60-day notification requirement for PHI breaches | ## HIPAA vs. SOC 2 ## SOC 2 + HIPAA Many healthcare SaaS companies pursue both. SOC 2 provides the independent audit report that healthcare buyers want to see, while HIPAA compliance is the legal requirement for handling PHI. About 60% of SOC 2 controls satisfy HIPAA requirements, so doing both is more manageable than doing them separately. ## Getting Started 1. Determine if you actually handle PHI (many SaaS companies don't) 2. If yes, build the HIPAA control foundation: risk analysis, safeguards, BAA process, PHI data mapping, breach notification 3. Add SOC 2 when a buyer asks for an independent report; most of the controls are already in place 4. Have a lawyer draft your BAA template --- ### What is HIPAA compliant software? *Keywords: HIPAA compliant software, hipaa-compliant software, HIPAA compliant software development, HIPAA software requirements* *Source: https://screenata.com/resources/answers/what-is-hipaa-compliant-software* ## What is HIPAA compliant software? **No software is HIPAA compliant on its own.** HIPAA imposes obligations on organisations, specifically covered entities and their business associates, not on products. What exists is software that can be *used* in a compliant way: it provides the safeguards the Security Rule requires, and the vendor will sign a **business associate agreement**. Compliance is a property of your organisation and its contracts, not a feature of a tool. ### What to actually check in a vendor | Requirement | What to ask for | |---|---| | **Signed BAA** | Will they sign one, without an enterprise upgrade? This is the gate. | | Access control | Unique user IDs, role-based access, no shared accounts | | Audit logging | Records of who accessed PHI, when, and what they did | | Encryption | In transit and at rest | | Automatic logoff | Sessions terminate after inactivity | | Integrity controls | PHI cannot be improperly altered or destroyed undetected | | Backup and recovery | Retrievable exact copies, tested | | Subcontractors | Their subprocessors carry obligations too, under the Omnibus Rule | **The BAA is the one that decides it.** A product with every technical safeguard and no BAA cannot be used with PHI. A product with a BAA and weak safeguards puts you in breach through your own risk analysis. You need both, and the BAA is the one people forget to check until procurement. ## There is no HIPAA certification HHS does not certify, accredit, or endorse any product, vendor, or organisation. A "HIPAA certified" badge is either self-issued or issued by a private company with no regulatory standing. What healthcare buyers accept instead: 1. A **signed BAA**, which is a contract rather than a certificate 2. A **SOC 2 Type II report**, often with HIPAA criteria mapped into scope 3. Your **risk analysis and safeguard documentation** See [how much does HIPAA certification cost](/resources/answers/how-much-does-hipaa-certification-cost) for what the alternatives actually cost. ## If you are building the software You are likely a **business associate** with direct legal obligations the moment you handle PHI for a covered entity, regardless of your size. That means a documented risk analysis, implemented safeguards, signed BAAs both upstream and downstream, and evidence that all of it operates. The Security Rule's safeguards overlap heavily with the SOC 2 Common Criteria, particularly CC6 for access control and CC7 for operations, which is why most healthcare SaaS vendors pursue SOC 2 and map HIPAA into it rather than running two programmes. See [what controls overlap between SOC 2, ISO 27001, and HIPAA](/resources/answers/what-controls-overlap-between-soc-2-iso-27001-and-hipaa). --- ### What is HITRUST and why do hospitals require it? *Keywords: HITRUST certification, HITRUST for SaaS, healthcare compliance* *Source: https://screenata.com/resources/answers/what-is-hitrust-and-why-do-hospitals-require-it* ## What Is HITRUST? HITRUST CSF (Common Security Framework) is a comprehensive security framework that harmonizes requirements from multiple standards, HIPAA, NIST 800-53, ISO 27001, PCI DSS, and others, into a single assessable framework. Unlike HIPAA (which is self-attested), HITRUST provides formal certification through an authorized assessor. ## Why Hospitals Require HITRUST | Reason | Explanation | |--------|-------------| | HIPAA gaps | HIPAA is self-attested, anyone can claim compliance. HITRUST proves it. | | Risk reduction | Hospitals face severe penalties for data breaches. HITRUST reduces their vendor risk. | | Insurance requirements | Some malpractice insurers require vendors to have HITRUST certification | | Industry standard | Large health systems have standardized on HITRUST for vendor evaluation | | Regulatory alignment | HITRUST maps to multiple regulatory requirements in one assessment | ## HITRUST vs. SOC 2 vs. HIPAA ## When to Pursue HITRUST Most SaaS startups don't need HITRUST immediately. The typical path: 1. **Start with SOC 2**, covers general security controls, accepted by most buyers 2. **Add HIPAA compliance**, if you handle PHI, sign BAAs with healthcare customers 3. **Pursue HITRUST**, when large health systems require it as a condition of doing business HITRUST is worth the investment when you're selling to hospital systems with 500+ beds, large health plans, or government healthcare contracts. For smaller healthcare buyers, SOC 2 + HIPAA is usually sufficient. --- ### What is IPE (Information Produced by Entity) in SOC 2? *Keywords: IPE SOC 2, information produced by entity, audit evidence validation* *Source: https://screenata.com/resources/answers/what-is-ipe-in-soc-2* ## What Is IPE? IPE stands for Information Produced by Entity. It's any data your organization creates or exports that an auditor uses as audit evidence. When you pull a user list from your admin panel, export AWS IAM policies, or generate a log report, that output is IPE. The key concern: auditors need to trust that your data is accurate. They can't just accept a spreadsheet at face value. ## Examples of IPE | IPE Type | Example | What Auditors Check | |----------|---------|-------------------| | User access list | Export of all users from Google Workspace | Is the list complete? Does it match the actual system? | | Configuration export | AWS security group rules as JSON | Was this exported from the real environment? | | Log data | Authentication logs showing MFA usage | Are the logs tamper-proof? Do they cover the full period? | | Custom reports | Dashboard export showing access review completion | How was this report generated? Is the data reliable? | ## How Auditors Validate IPE Auditors don't just accept your exports. They verify IPE through: 1. **Completeness testing:** Comparing your exported user list against a sample check in the actual system 2. **Accuracy testing:** Spot-checking a few entries against the source system 3. **Source verification:** Confirming the data came from the actual production system (not a test environment) ## Why This Matters for Startups IPE validation is where many startups get tripped up. You export a user list, but the auditor finds two accounts missing from the export. Or you provide a log report, but the auditor questions whether the reporting tool captures all events. **Best practices:** - Use direct screenshots of admin consoles alongside CSV exports - Show the auditor the system the data came from (live or screenshot) - Ensure exports include timestamps and are from production environments - Use tools that generate evidence with built-in traceability Screenata addresses IPE concerns by capturing evidence directly from your systems with timestamps, screenshots, and metadata that auditors can independently verify. --- ### What is ISO 27001 and how is it different from SOC 2? *Keywords: ISO 27001 vs SOC 2, certification comparison, which compliance first* *Source: https://screenata.com/resources/answers/what-is-iso-27001-and-how-is-it-different-from-soc-2* ## Key Differences ## When to Choose SOC 2 - Your customers are primarily US-based - Enterprise buyers ask for "SOC 2" specifically - You want a faster, less formal process - You're a startup with limited budget and need to move quickly ## When to Choose ISO 27001 - Your customers are international (EU, UK, Asia-Pacific) - Buyers specifically ask for ISO 27001 - You want a 3-year certification instead of annual reports - You're pursuing government or highly regulated contracts ## Control Overlap About 70-80% of controls overlap between SOC 2 and ISO 27001. If you implement one, pursuing the other is significantly easier. Key shared areas: - Access control - Change management - Risk assessment - Incident response - Vendor management - Data protection ## The Common Path for Startups Most US B2B SaaS startups start with SOC 2 because US enterprise buyers ask for it first. If international expansion creates ISO 27001 demand, they add it later, reusing 70-80% of their SOC 2 controls and evidence. --- ### What is NIST 800-53? *Keywords: NIST 800-53, NIST 800 53, what is NIST 800 53, NIST SP 800-53 controls, NIST 800-53 control families* *Source: https://screenata.com/resources/answers/what-is-nist-800-53* ## What is NIST 800-53? NIST SP 800-53 is a **catalogue of security and privacy controls** for information systems, published by the US National Institute of Standards and Technology. Revision 5 organises roughly 1,000 controls and enhancements into **20 families**, and companion baselines select which apply at low, moderate, and high impact levels. It is mandatory for federal systems under FISMA and voluntary everywhere else, where it is most valuable as a crosswalk hub. ### The 20 control families | Code | Family | Code | Family | |---|---|---|---| | AC | Access Control | PE | Physical and Environmental Protection | | AT | Awareness and Training | PL | Planning | | AU | Audit and Accountability | PM | Program Management | | CA | Assessment, Authorization, Monitoring | PS | Personnel Security | | CM | Configuration Management | PT | PII Processing and Transparency | | CP | Contingency Planning | RA | Risk Assessment | | IA | Identification and Authentication | SA | System and Services Acquisition | | IR | Incident Response | SC | System and Communications Protection | | MA | Maintenance | SI | System and Information Integrity | | MP | Media Protection | SR | Supply Chain Risk Management | Revision 5 added the PT privacy family and the SR supply chain family, and made the controls outcome-based rather than written specifically for federal systems, which is what made commercial adoption practical. ## You do not implement all thousand The catalogue is deliberately exhaustive. **SP 800-53B** defines baselines that select a subset by impact level, and a tailoring process narrows further based on your system. A moderate baseline is a few hundred controls, not a thousand. ## Why commercial teams care: the crosswalk This is the reason 800-53 matters to a company with no federal customers. It is the most complete control catalogue in wide use, so **other frameworks map onto it** rather than onto each other. Map a control to 800-53 once and you inherit its relationships to SOC 2 Common Criteria, ISO 27001 Annex A, and the HIPAA Security Rule. That turns the second framework into a fraction of the work of the first. One access-control test, evidenced once, satisfies SOC 2 CC6, ISO 27001 A.5.15, and the HIPAA access management standard at the same time. Screenata uses NIST 800-53 as exactly this hub, which is why an additional framework **reuses the evidence you already collected** rather than starting a second program. The evidence crosswalks; it is not collected twice. ## Where 800-53 is actually mandatory - **Federal information systems**, under FISMA - **FedRAMP**, which builds its baselines from 800-53 - **Contractors** by flow-down, though CUI obligations usually arrive as [NIST SP 800-171](/resources/answers/what-is-nist-sp-800-171) instead For everyone else it is a reference, not a requirement. There is no such thing as being "NIST 800-53 certified"; there is no certification scheme. --- ### What is NIST SP 800-171? *Keywords: NIST SP 800-171, NIST special publication 800 171, NIST 800 53 vs 800 171, CUI requirements, CMMC Level 2* *Source: https://screenata.com/resources/answers/what-is-nist-sp-800-171* ## What is NIST SP 800-171? NIST SP 800-171 defines **110 security requirements across 14 families** for protecting **Controlled Unclassified Information** on nonfederal systems. It applies to contractors and subcontractors that handle CUI for the US government, arrives through DFARS or agency contract clauses, and forms the technical basis of CMMC Level 2. It is a derived subset of NIST 800-53's moderate baseline rather than an independent framework. ### The 14 requirement families Access Control · Awareness and Training · Audit and Accountability · Configuration Management · Identification and Authentication · Incident Response · Maintenance · Media Protection · Personnel Security · Physical Protection · Risk Assessment · Security Assessment · System and Communications Protection · System and Information Integrity 110 requirements distributed across those 14. Substantially smaller than 800-53, and that is the point: it is scoped to one problem, protecting CUI outside federal systems. ## 800-53 or 800-171, and how to tell | | NIST 800-53 | NIST SP 800-171 | |---|---|---| | Applies to | Federal information systems | Nonfederal systems holding CUI | | Size | ~1,000 controls, 20 families | 110 requirements, 14 families | | Enforced by | FISMA, FedRAMP | DFARS and agency contract clauses | | Relationship | The catalogue | A derived, tailored subset | | Certification | None | Via CMMC for most Level 2 contracts | The practical test: if a federal agency runs the system, 800-53. If you are a company holding government information on your own systems, 800-171. ## What CUI actually is Information the government creates or possesses, or that an entity creates for the government, which requires safeguarding under law or policy but is **not classified**. Technical drawings, research data, procurement information. The contract that imposes the obligation should identify the CUI categories involved, and if it does not, that is a question to ask before signing rather than after. ## The CMMC relationship CMMC does not replace 800-171, it verifies it. The 110 requirements stay the same; CMMC decides who assesses them and how. Level 2 requires third-party assessment for most contracts, replacing the self-attested SPRS score that preceded it. ## Honest scope note Screenata supports SOC 2, HIPAA, ISO 27001, and ISO 42001 through a NIST 800-53 hub. **We do not currently support NIST 800-171 or CMMC as enrollable frameworks.** Because 800-171 derives from the 800-53 moderate baseline, much of the underlying evidence overlaps with work an existing programme already produces, but the assessment path and the requirement mapping are not something we ship today. --- ### Is PCI DSS a regulation? *Keywords: PCI DSS regulatory compliance, is PCI DSS a regulation, PCI DSS compliance, PCI compliance levels* *Source: https://screenata.com/resources/answers/what-is-pci-dss-compliance* ## Is PCI DSS a regulation? **No.** PCI DSS is a **contractual security standard**, not a law. It is maintained by the PCI Security Standards Council, founded by the major card brands, and enforced through your merchant agreement by your acquiring bank rather than by a regulator. Non-compliance produces fines, higher fees, or loss of card processing, not regulatory penalties. A few US states reference it in legislation, but the enforcement mechanism is commercial. ### How it differs from actual regulation | | PCI DSS | HIPAA / GDPR | |---|---|---| | Source | Card brands via the PCI SSC | Legislation | | Binds you through | Your merchant agreement | Law | | Enforced by | Acquiring bank, card brands | HHS, data protection authorities | | Penalty | Fines via acquirer, fee increases, loss of processing | Statutory penalties, enforcement actions | | Opt out by | Not accepting cards | You cannot | The practical difference: you can leave PCI DSS scope entirely by not handling card data, which is why so much of PCI advice is about **reducing scope** rather than meeting requirements. Redirecting payments to a hosted page from a compliant processor removes most of your environment from scope, and that is usually a better investment than hardening it. ## Validation depends on your level Levels are set by annual transaction volume and differ slightly by card brand. | Level | Roughly | Validation | |---|---|---| | 1 | Over 6 million transactions a year | Report on Compliance by a Qualified Security Assessor | | 2 | 1 to 6 million | SAQ, sometimes a QSA depending on brand | | 3 | 20,000 to 1 million ecommerce | Self-Assessment Questionnaire | | 4 | Under 20,000 ecommerce | Self-Assessment Questionnaire | Most startups are Level 4 and complete an SAQ. Which SAQ type applies depends on how card data flows: **SAQ A** for fully outsourced ecommerce is the shortest by a wide margin, which is another reason scope reduction pays. ## Where PCI overlaps what you already do If you hold SOC 2 or ISO 27001, a meaningful share of PCI's twelve requirements is already covered: access control, encryption, logging, vulnerability management, and policy. What PCI adds that neither tests is **cardholder data environment segmentation** and requirements specific to card data storage and transmission. ## Honest scope note Screenata supports SOC 2, HIPAA, ISO 27001, and ISO 42001. **PCI DSS is a Tier 1 framework on our price list but is not seeded as an enrollable framework today**, so treat this page as an explanation rather than a coverage claim. The underlying evidence overlaps substantially with a SOC 2 programme, which is the honest thing to say about the relationship. --- ### What is risk management? *Keywords: define risk management, what is risk management, cyber security risk management, define risk mitigation, risk control in risk management* *Source: https://screenata.com/resources/answers/what-is-risk-management* ## What is risk management? Risk management is the process of **identifying what could stop an organisation meeting its objectives**, assessing how likely and how damaging each is, deciding what to do, and checking the decision worked. **ISO 31000** is the general standard and defines risk as the effect of uncertainty on objectives, which is why the objectives come first: without them there is no way to say what counts as a risk. ### The process | Step | Question it answers | |---|---| | **Identify** | What could go wrong, and to what? | | **Analyse** | How likely, and how bad? | | **Evaluate** | Is that acceptable against our risk appetite? | | **Treat** | Avoid, reduce, transfer, accept, or share | | **Monitor and review** | Did the treatment work, and has anything changed? | The output of steps one to four is a [risk register](/resources/answers/what-is-a-risk-register). Step five is what most programmes drop after the first year. ## Risk management, mitigation, and control These get used interchangeably and are not the same. - **Risk management** is the whole process above. - **Risk mitigation**, more precisely **reduction**, is one of five treatments: lowering likelihood or impact through controls. - **A control** is the specific safeguard implementing a treatment. MFA is a control; reducing account-takeover risk is the treatment; the register entry is the management. The five treatments in full: avoid, reduce, transfer, accept, share. See [what are the five risk mitigation strategies](/resources/answers/what-are-the-five-risk-mitigation-strategies). ## Why compliance frameworks insist on it Because it is what makes a control set defensible. A company that implements controls without a risk assessment has copied a template, and neither it nor its auditor can say whether those controls address anything the business actually faces. | Framework | Where it appears | |---|---| | SOC 2 | CC3 series, risk identification and analysis | | ISO 27001 | Clause 6.1, with a documented methodology | | HIPAA | Security Rule risk analysis, the most frequently cited enforcement gap | | NIST 800-53 | RA control family | **HIPAA is the sharpest example.** A missing or inadequate risk analysis is one of the most common findings in HHS enforcement actions, more so than the technical failures people expect. ## Cyber security risk management specifically Same process, narrowed to information assets and threats. The differences in practice are that the threat landscape changes faster, so review cadence matters more, and that many risks are concentrated in third parties rather than your own systems, which is why vendor risk gets its own register. ## The order that gets reversed Most small compliance programmes start by collecting evidence, then work backwards to controls, and never do the risk assessment at all. That produces evidence for controls nobody chose, and gaps in the ones that mattered. Risk assessment first, controls from the assessment, evidence from the controls. --- ### What is SOC 2 and why do startups need it? *Keywords: SOC 2 for startups, what is SOC 2, why SOC 2 matters* *Source: https://screenata.com/resources/answers/what-is-soc-2-and-why-do-startups-need-it* ## What Is SOC 2? SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA that evaluates whether your organization's controls adequately protect customer data. A licensed CPA firm examines your security policies, processes, and evidence, then issues a report with their opinion on whether your controls meet the Trust Services Criteria. SOC 2 is not a certification you pass or fail. It is an auditor's opinion on your control environment, documented in a formal report that you share with customers and prospects. ## Why Do Startups Need SOC 2? The short answer: enterprise buyers require it. When a startup sells to mid-market or enterprise companies, the buyer's security team will ask for a SOC 2 report during vendor review. Without one, deals stall or die. | Scenario | Without SOC 2 | With SOC 2 | |----------|--------------|------------| | Enterprise sales | Weeks of security questionnaires, often rejected | Share report, move to contract | | Investor diligence | Red flag for Series A+ | Demonstrates operational maturity | | Partnership agreements | Manual security reviews each time | Report satisfies partner requirements | | Competitive deals | Competitor with SOC 2 wins | Level playing field | ## What Does SOC 2 Cover? SOC 2 evaluates your controls against five Trust Services Criteria: 1. **Security** (required), Protection against unauthorized access 2. **Availability**, System uptime and performance commitments 3. **Processing Integrity**, Accuracy and completeness of data processing 4. **Confidentiality**, Protection of confidential information 5. **Privacy**, Collection, use, and disposal of personal information Most startups scope their first audit to Security only. This covers the controls enterprise buyers care about most and keeps the audit manageable. ## When Should a Startup Get SOC 2? Get SOC 2 when enterprise prospects start asking for it, typically when you are selling to companies with 200+ employees or operating in regulated industries. Starting too early wastes resources. Starting too late costs you deals. --- ### What counts as SOC 2 evidence? *Keywords: SOC 2 evidence, SOC 2 audit evidence, compliance evidence examples, SOC 2 controls evidence* *Source: https://screenata.com/resources/answers/what-is-soc-2-evidence* ## What Counts as SOC 2 Evidence? SOC 2 evidence is any artifact that demonstrates your security controls are implemented and operating effectively. Auditors need proof, not promises, that your organization follows the policies it claims to follow. Evidence falls into several categories: | Evidence Type | Examples | Used For | |---------------|----------|----------| | Screenshots | Access control settings, MFA configs, firewall rules | Proving configuration at a point in time | | Configuration exports | IAM policies, security group rules, encryption settings | Machine-readable proof of controls | | Logs | Audit trails, access logs, change management records | Proving ongoing operation | | Policy documents | Information security policy, incident response plan | Proving governance exists | | Tickets/records | Change requests, access reviews, incident reports | Proving processes are followed | ## How Much Evidence Do Auditors Need? For a SOC 2 Type I audit, auditors need evidence that controls are designed and implemented at a single point in time. For Type II, they need evidence covering the entire audit period (typically 3–12 months), showing controls operated consistently. Most organizations collect 50–200 pieces of evidence per audit. The exact number depends on the Trust Services Criteria in scope (Security, Availability, Processing Integrity, Confidentiality, Privacy). ## Where Does Screenata Fit? Screenata automates the collection of application-level evidence, the screenshots, configuration exports, and control validations that GRC platforms like Drata and Vanta cannot capture automatically. Instead of manually taking screenshots and organizing them, Screenata records your workflow and generates audit-ready evidence with full traceability. --- ### What is the 8 4 rule for passwords? *Keywords: 8 4 rule passwords, 8-4 password rule, password complexity requirements, NIST password guidelines, SOC 2 password policy, 8 4 password rule* *Source: https://screenata.com/resources/answers/what-is-the-8-4-rule-for-passwords* ## What is the 8 4 rule for passwords? The 8-4 rule requires a password of **at least 8 characters containing all 4 character types**: one uppercase letter, one lowercase letter, one number, and one special character. It was the default corporate password standard for roughly two decades and is still built into many identity providers as a preset. It is a composition rule, meaning it governs what a password contains rather than how hard it is to guess. ### The four character types | Type | Example characters | |---|---| | Uppercase | A to Z | | Lowercase | a to z | | Numeric | 0 to 9 | | Special | ! @ # $ % ^ and similar | ## Why NIST moved away from it **NIST SP 800-63B** advises against imposing composition rules. The reasoning is behavioural rather than mathematical: when a rule demands all four types, people satisfy it in the same predictable way. The capital goes first, the number and the exclamation mark go last, and a substitution replaces a letter with a lookalike. `Password1!` satisfies the 8-4 rule. So does `Summer2026!`. Attackers know these patterns and encode them in cracking rules, so the search space is far smaller than the character count implies. What NIST recommends instead: - **A longer minimum**, commonly 8 characters as a floor but with support for much longer passphrases - **Screening against known breached passwords**, which removes the credentials attackers actually try first - **No mandatory periodic expiry** unless there is evidence of compromise, since forced rotation produces incremental variants - **Allowing all characters including spaces**, and not truncating ## What SOC 2 and ISO 27001 actually require Neither prescribes a length or a composition rule. - **SOC 2** CC6.1 requires logical access controls appropriate to your assessed risk. The auditor tests that the settings configured in your identity provider match what your written policy claims. - **ISO 27001** Annex A 5.17 covers authentication information and expects a defined, followed process rather than a specific rule. The failure mode in an audit is almost never the rule you chose. It is a policy that says one thing while the identity provider is configured to do another, because the policy was written from a template and the setting was left at its default. ## A defensible modern policy 1. Minimum 12 characters, no composition requirement 2. Screen new passwords against a breached-password list 3. Enforce MFA, which does more than any password rule on this page 4. No scheduled expiry, with forced reset on suspected compromise 5. Make sure the written policy matches the configured setting, in both directions --- ### What is the best AI compliance tool for SOC 2 in 2026? *Keywords: AI compliance tools 2026, best AI SOC 2 tool, AI audit prep* *Source: https://screenata.com/resources/answers/what-is-the-best-ai-compliance-tool-for-soc-2-in-2026* ## The AI Compliance Landscape in 2026 AI compliance tools are a new category, distinct from traditional GRC platforms. Instead of providing a dashboard and templates, they actively do the compliance work: analyzing your systems, writing policies, and collecting evidence. ## What to Look For | Feature | Why It Matters | |---------|---------------| | Codebase analysis | Policies generated from your actual code are more accurate than templates | | Application-level evidence | Infrastructure monitoring alone misses 40% of SOC 2 evidence | | Control mapping | Automatic mapping of your systems to TSC criteria saves hours | | Gap identification | Proactively finding missing controls before the audit | | Evidence organization | Evidence mapped to controls and ready for auditor review | | Ongoing monitoring | Detecting when systems change and policies need updates | | Verifiable evidence | Signed, timestamped artifacts an auditor can independently confirm, the post-Delve trust test | ## The Verifiability Test (New in 2026) The Delve collapse in April 2026, where 493 of 494 SOC 2 reports turned out to be near-identical boilerplate, made "AI compliance" claims something auditors now scrutinize rather than trust. The dividing line in 2026 is **verifiability**: can the tool prove its output is real, specific to you, and untampered? - **Cryptographically signed evidence** (RSA/ECDSA signatures, RFC 3161 timestamps, per-artifact hashing) lets an auditor confirm nothing was altered after capture. - **Claim traceability** ties every policy statement back to the system it describes, so it's not a generic template. - **Overpromise detection** flags policies claiming controls you don't actually run, the #1 audit-failure mode. A tool that can't demonstrate these is asking you to take "AI did it" on faith, which, post-Delve, auditors no longer do. ## Screenata Screenata is an AI compliance officer built for startups. It connects to your GitHub repos and cloud accounts, reads your codebase, and generates SOC 2 policies and evidence. **Key differentiator:** Codebase-aware policy generation, policies reference your actual tools and configurations. **Best for:** Startups under 50 employees pursuing SOC 2 for the first time. ## How the Landscape Compares | Tool | What it is | AI scope | Verifiable evidence | |------|-----------|----------|---------------------| | **Screenata** | AI compliance officer | Reads codebase, writes policies, collects evidence | Signed + traceable | | **Vanta / Drata** | GRC platforms adding AI features | AI bolted onto API monitoring; still template policies, still need someone to operate them | Monitoring logs, not signed packages | | **Delve (defunct)** | AI-first GRC | Black-box generation | Collapsed April 2026 over boilerplate reports | Vanta and Drata remain strong API-monitoring platforms, but their AI is a layer on a dashboard built for teams that already have compliance expertise. The codebase-aware, verifiable-by-default approach is what distinguishes a true AI compliance tool from a GRC platform with AI branding. ## How to Evaluate AI Compliance Tools --- ### What is the best certification for healthcare compliance? *Keywords: best certification for healthcare compliance, HITRUST vs SOC 2, HIPAA certification for companies, healthcare compliance for SaaS* *Source: https://screenata.com/resources/answers/what-is-the-best-certification-for-healthcare-compliance* ## What is the best certification for healthcare compliance? For an organization, there is no official one to get: HIPAA has no government-issued certification. So "best" means the credential healthcare buyers actually accept as a proxy, and for a healthcare SaaS company that is a SOC 2 Type II report with HIPAA mapping, the item most requested in vendor security reviews. Hospital systems and payers often require HITRUST instead. ISO 27001 carries weight internationally. Underneath all of them sits the legal baseline: a signed BAA and a documented risk assessment. One disambiguation first. If you searched this asking about a personal career credential, the widely recognized one is Certified in Healthcare Compliance (CHC), issued by the Compliance Certification Board, with siblings for privacy and research compliance. Those certify a compliance professional, not a company, and no buyer will accept an employee's CHC as evidence about your product. The rest of this page is about credentials for organizations. ### The four paths healthcare buyers accept The fourth row is not optional, whichever credential you pursue. A vendor with a HITRUST letter and no BAA is still out of compliance the day PHI arrives. ## Why SOC 2 with HIPAA mapping wins for startups Because it matches what the buyer's reviewer is actually holding: a security questionnaire that asks for a SOC 2 report. Adding HIPAA criteria to the same examination, a HIPAA mapping or a combined SOC 2 + HIPAA attestation from the same auditor, answers the health-specific questions without a second program. The cost sits far below HITRUST, the timeline fits a sales cycle, and the same evidence base serves both. HITRUST exists for the buyers who will not accept anything less. Its r2 level involves hundreds of controls and an assessor engagement priced accordingly, which is why the sensible trigger is a named enterprise deal that requires it, with the lighter e1 as the entry point. Certifying ahead of demand is how startups spend six figures on a credential no open deal asked for. ## The honest limits of every option None of these makes you "HIPAA certified," because that status does not exist. A SOC 2 report is an attestation by a CPA firm, not a certification. HITRUST is a certification, but by a private company against its own framework. ISO 27001 is a certification against an international standard that says nothing about HIPAA specifically. Buyers know all this; they ask for these proxies because proxies plus a BAA are the best available signal that a vendor takes PHI seriously. What each one costs is covered in more depth in [how much a HIPAA audit costs](/resources/answers/how-much-does-a-hipaa-audit-cost). ## Where Screenata fits --- ### What is the best compliance tech stack for a B2B SaaS startup? *Keywords: compliance tech stack, SOC 2 tool stack, SaaS compliance tools* *Source: https://screenata.com/resources/answers/what-is-the-best-compliance-tech-stack-for-a-b2b-saas-startup* ## The Compliance Tech Stack You don't need to buy a dozen security products to pass SOC 2. Most B2B SaaS startups already have 80% of what they need. The stack breaks into three layers: ## Layer 1: What You Already Have | Tool | SOC 2 Purpose | You Probably Already Use | |------|---------------|------------------------| | Cloud provider (AWS, GCP, Vercel) | Infrastructure security, logging | Yes | | GitHub/GitLab | Change management, code review | Yes | | Google Workspace / Okta | Identity, MFA, access control | Yes | | Slack | Incident communication | Yes | ## Layer 2: What You Might Need to Add ## Layer 3: Compliance-Specific Tools This is where you choose your approach: ## The Key Insight --- ### What is the best GRC tool? *Keywords: best GRC tool, best GRC software, best risk management software, compliance software, GRC platform comparison* *Source: https://screenata.com/resources/answers/what-is-the-best-grc-tool* ## What is the best GRC tool? There is no single best GRC tool, and the useful question is which **generation** of tool your situation calls for. Enterprise GRC suites serve staffed risk functions managing many registers. Compliance automation platforms serve teams pursuing a certification who have somebody available to drive the platform. Agent-first tools serve small teams with nobody to spare, where the software has to perform the work rather than track it. ### Four generations of compliance tooling | Generation | Shape | Who does the work | |---|---|---| | 1 | The spreadsheet | You do it, and you remember where the evidence went | | 2 | The dashboard | You do it; the software tells you what is missing | | 3 | The assistant | AI drafts and suggests; you still do it, and now you also check the AI | | 4 | The coworker | The agent owns the item, does it, and every action traces to a claim, a test, and an artifact | The break is who does the work, not who has AI. A dashboard that adds a chat window is still a dashboard. ## The categories, and who each fits **Enterprise GRC suites** (Archer, MetricStream, ServiceNow GRC, LogicGate, Riskonnect). Built for large organisations with a risk function: enterprise risk registers, policy lifecycle, audit management, regulatory change tracking. Implementation is a project. If you have a risk team, this is the category. If you have a CTO doing compliance on Fridays, it is not. **Compliance automation platforms** (Vanta, Drata, Secureframe, Sprinto, Scrut). Connect to cloud, identity, and HR systems, monitor controls continuously against a framework, and surface what needs evidence. Broad integration catalogs and mature ecosystems. Pricing is generally sales-gated on annual contracts. The model assumes a person available to work the queue the platform produces. ## Five questions that actually separate them Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## The honest answer for most small teams If you need a certificate to unblock a deal and have nobody to run a platform, the deciding question is question one. A dashboard listing 200 outstanding items has told you the size of the problem, not solved any of it. If you have a staffed risk function and multiple regulatory regimes, an enterprise suite is the right category and this page is not the comparison you need. --- ### What is the best order to pursue multiple compliance frameworks? *Keywords: compliance framework order, certification sequence, multi-framework plan* *Source: https://screenata.com/resources/answers/what-is-the-best-order-to-pursue-multiple-compliance-frameworks* ## The Recommended Order Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ### Step 2: Add Based on Demand | If You Need | Add This | Overlap with SOC 2 | Added Timeline | |-------------|----------|-------------------|----------------| | International sales | ISO 27001 | 70-80% | 2-4 months | | Healthcare customers | HIPAA | 60-70% | 1-2 months | | Payment processing | PCI DSS | 40-50% | 3-6 months | | Hospital systems | HITRUST | 50-60% | 6-12 months | | US government | FedRAMP | 30-40% | 6-18 months | | Defense contracts | CMMC | 30-40% | 4-8 months | ### Step 3: Maintain and Expand After establishing your initial frameworks, the ongoing work is maintenance, annual audits, continuous evidence collection, and policy updates when systems change. ## What NOT to Do ## The Compounding Benefit Each additional framework gets easier: - **First framework (SOC 2):** Hardest, building everything from scratch - **Second framework (ISO or HIPAA):** 50-80% of work is already done - **Third framework:** 60-90% of work is already done The key is building a strong evidence and control foundation with SOC 2 that subsequent frameworks can build on. ## Practical Example A B2B SaaS company selling to US healthcare: 1. **Month 1-4:** SOC 2 Type I → immediately useful for enterprise sales 2. **Month 4-6:** Add HIPAA → opens healthcare market 3. **Month 6-10:** SOC 2 Type II → strengthens enterprise credibility 4. **Year 2:** ISO 27001 → opens international markets 5. **Year 2-3:** HITRUST (if large health systems require it) --- ### What is the best pentesting tool? *Keywords: best pentesting tool, penetration testing tools, Burp Suite vs OWASP ZAP, penetration test cost, pentest for SOC 2* *Source: https://screenata.com/resources/answers/what-is-the-best-pentesting-tool* ## What is the best pentesting tool? ## A tool is not a pentest The question hides an ambiguity worth resolving. A penetration test is a service: a person attempts to break into your systems, chains findings together, and writes a report a third party will accept. A pentesting tool is something that person uses. Companies that need to hand a customer or auditor a pentest report cannot substitute a tool, because the deliverable is the tester's judgment, and buyers check who performed the test. Automated scanners are the common trap. A vulnerability scan finds known issues; a penetration test demonstrates what an attacker can do with them. Auditors and enterprise security reviewers know the difference, and a scan report labeled as a pentest tends to get rejected in exactly the reviews it was purchased for. ## The tools and services, by what they do | Tool or service | What it is for | Cost model | |---|---|---| | Burp Suite | Web application testing; the industry-standard intercepting proxy and scanner | Free Community Edition; paid Professional license | | Nmap | Network discovery and port scanning; the first step of most engagements | Free, open source | | Metasploit | Exploitation framework for validating that vulnerabilities are actually exploitable | Open source framework; commercial Pro edition | | OWASP ZAP | Free web application scanner; the main open source alternative to Burp | Free, open source | | Cobalt | Pentest as a service: human testers delivered through a platform | Commercial, per-engagement or subscription | | HackerOne | PTaaS and bug bounty programs with a vetted researcher community | Commercial, per-engagement or program-based | ## Which one is actually best For learning and internal testing, start with OWASP ZAP and Nmap, both free, then move to Burp Suite Professional when you outgrow them; it is what most working testers use daily. For validating exploitability, Metasploit remains the reference framework. For a company that needs a report, the choice is between a traditional consultancy and a PTaaS platform. Consultancies offer deeper scoping conversations and are the safer choice for unusual environments. PTaaS platforms like Cobalt and HackerOne are faster to start, produce reports enterprise buyers recognize, and fit companies that expect to retest annually. Either way, ask who the individual testers are and whether the report includes retesting of fixed findings, because customers reviewing the report will ask you the same thing. ## Where this fits a SOC 2 program SOC 2 does not strictly require a penetration test, but enterprise customers usually do, so most companies pursuing SOC 2 commission one annually and after major changes. The pentest report, the remediation of its findings, and the retest letter all become evidence in your compliance program. Screenata tracks that report and its remediation trail as evidence inside a [SOC 2 program](/solutions/soc-2); it does not perform penetration testing itself, and the firms and platforms above are the right place to buy one. --- ### What is the best SOC 2 automation tool for startups in 2026? *Keywords: best SOC 2 tool 2026, SOC 2 tools startups, affordable SOC 2 platform* *Source: https://screenata.com/resources/answers/what-is-the-best-soc-2-automation-tool-for-startups-in-2026* ## SOC 2 Tools in 2026 The SOC 2 tooling market has evolved beyond GRC dashboards. In 2026, startups have three main approaches: Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## What's Changed in 2026 The other change: auditors are more comfortable with AI-generated evidence and policies, as long as the underlying data is accurate and traceable. That last condition got stricter in April 2026, when Delve collapsed after 493 of 494 of its SOC 2 reports were found to be near-identical boilerplate. The fallout made auditors scrutinize "AI did it" claims instead of accepting them, so a tool's ability to *prove* its output is real (signed artifacts, timestamps, evidence traced to the specific system it came from) is now a selection criterion, not a nice-to-have. When comparing tools in 2026, ask each one how an auditor would independently verify what it produced. ## Top Tools by Category ## How to Decide If your startup has someone who understands SOC 2 and just needs a monitoring tool, a GRC platform works. If you're a founder or CTO handling SOC 2 for the first time, an AI compliance tool gets you to audit-ready faster and cheaper because it provides the expertise that GRC platforms lack. --- ### What is the cheapest path to SOC 2 for a startup? *Keywords: cheapest SOC 2, startup SOC 2 path, SOC 2 minimum cost* *Source: https://screenata.com/resources/answers/what-is-the-cheapest-path-to-soc-2-for-a-startup* ## What Is the Minimum I Can Spend on SOC 2? ## The Cheapest Path Step by Step ## Cost Comparison by Path Team time includes fixing the controls, not just the paperwork. A Type I needs far fewer hours than a Type II, because it tests design at a point in time rather than twelve months of operation. Spreadsheets take the most hours of any path, because your team also builds the tracker, gathers every artifact by hand, and re-checks by hand what a platform monitors, so skipping the licence ends up costing more. Some vendors also sell the audit inside the platform price. The question there is not the line items but whether the report survives your customer's security review, so ask: does your platform vendor also provide your auditor? Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## Can You Do SOC 2 Completely DIY? ## What About Free SOC 2 Tools? Some vendors offer free tiers, but they typically require annual contracts once you need actual audit preparation features. The cheapest reliable path is a purpose-built AI tool combined with a budget-conscious auditor. --- ### What is the COSO framework? *Keywords: COSO framework, COSO enterprise risk management, ERM COSO framework, internal control framework, COSO 5 components* *Source: https://screenata.com/resources/answers/what-is-the-coso-framework* ## What is the COSO framework? The COSO framework is the **Internal Control Integrated Framework**, published by the Committee of Sponsoring Organizations of the Treadway Commission. It defines internal control through **five components and seventeen principles**, and it is the framework US public companies use to assess internal control over financial reporting under SOX 404. A separate COSO publication covers enterprise risk management, and the two are routinely conflated. ### The five components | Component | What it covers | |---|---| | **Control Environment** | Tone at the top, integrity, board oversight, accountability structures | | **Risk Assessment** | Objectives, identifying and analysing risks to meeting them, fraud risk | | **Control Activities** | The controls themselves, including over technology | | **Information and Communication** | Relevant information, communicated internally and externally | | **Monitoring Activities** | Ongoing and separate evaluations, and reporting deficiencies | The **2013 update** added seventeen principles distributed across those five. That is the change that made COSO assessable: a principle can be present and functioning, or not, whereas a component alone is too broad to test. ## COSO Internal Control and COSO ERM Two frameworks, one body, different jobs. | | Internal Control | ERM | |---|---|---| | Full name | Internal Control Integrated Framework | Enterprise Risk Management: Integrating with Strategy and Performance | | Scope | Internal control, principally financial reporting | Risk across the enterprise, tied to strategy | | Structure | 5 components, 17 principles | 5 components, 20 principles | | Used for | SOX 404 assessment | Enterprise risk programmes | If someone says "the COSO framework" without qualification, they almost always mean Internal Control. ## Why a SaaS company doing SOC 2 should care Because **SOC 2's Common Criteria are built on COSO's seventeen principles.** CC1 through CC5 map directly onto the five components: - CC1 → Control Environment - CC2 → Information and Communication - CC3 → Risk Assessment - CC4 → Monitoring Activities - CC5 → Control Activities This is why a SOC 2 audit asks about board oversight, organisational structure, and how you communicate policy, when a team expecting a purely technical audit finds those questions surprising. They are COSO questions inherited wholesale. The practical consequence: CC1 through CC5 are the criteria least amenable to automation, because they are about governance rather than configuration. Evidence there is org charts, board minutes, policy acknowledgements, and role definitions. See [what are the 4 components of GRC](/resources/answers/what-are-the-4-components-of-grc) for the adjacent model. --- ### What is the difference between a policy and a procedure for SOC 2? *Keywords: SOC 2 policy vs procedure, security policy vs SOP* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-a-policy-and-a-procedure-for-soc-2* ## Policy vs. Procedure | Aspect | Policy | Procedure | |--------|--------|-----------| | Purpose | States the rule | Explains how to follow it | | Audience | Everyone in the company | People performing the task | | Level of detail | High-level principles | Step-by-step instructions | | Example | "All code changes require peer review" | "1. Create PR, 2. Assign reviewer, 3. Address feedback, 4. Get approval, 5. Merge" | | Frequency of change | Rarely (annual review) | Often (as processes evolve) | ## Why Auditors Need Both Policies alone tell auditors what you intend to do. Procedures prove it's repeatable. If your policy says "incidents are investigated within 24 hours" but you have no documented procedure for how an engineer triages an alert, the auditor may question whether the control is consistently followed. That said, not every policy needs a detailed procedure. Focus on areas where auditors will test operating effectiveness: ## Where You Need Detailed Procedures 1. **Incident response.** How does an engineer escalate an alert? Who gets notified? What gets documented? 2. **Change management.** How does a code change go from PR to production? What approvals are needed? 3. **Access provisioning and revocation.** How does a new employee get system access? How is access removed when someone leaves? 4. **User access reviews.** How often do you review who has access? What's the process? ## Where Policies Alone Are Sufficient - Data classification - Acceptable use - Vendor management - Security awareness training requirements ## Keep It Simple Startups don't need a 50-page procedure manual. A clear, one-page procedure for each critical process is enough. If your team can follow the steps and the auditor can verify them, you've met the bar. --- ### What is the difference between AI compliance tools and compliance platforms? *Keywords: AI compliance vs GRC, AI vs Drata, AI compliance tool comparison* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-ai-compliance-tools-and-compliance-platforms* ## Two Different Approaches ## How Compliance Platforms Work 1. You connect your cloud providers (AWS, GCP, Azure) 2. The platform monitors configurations and flags gaps 3. You write or customize policies using templates 4. You manually collect application-level evidence 5. You hire a consultant to fill the expertise gaps 6. You organize everything for the auditor ## How AI Compliance Tools Work 1. You connect your codebase and cloud accounts 2. The AI analyzes your actual systems 3. The AI writes policies referencing your specific tools 4. The AI collects both infrastructure and application evidence 5. The tool guides you through any remaining manual steps 6. Evidence is organized and mapped to controls automatically ## When to Use Which **Use a compliance platform if:** - You have a security or compliance team - Your team already understands SOC 2 - You want a monitoring dashboard for ongoing compliance - You're large enough (50+ employees) to justify the cost **Use an AI compliance tool if:** - Your team has no compliance expertise - You're doing SOC 2 for the first time - You want to avoid hiring a consultant - You're a small startup that needs cost-efficiency ## The Convergence The market is moving toward AI-enhanced compliance tools. Even traditional GRC platforms are adding AI features. But the fundamental difference remains: does the tool assume expertise or provide it? --- ### What is the difference between configuration evidence and population evidence? *Keywords: configuration vs population, SOC 2 evidence types, design vs operating* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-configuration-evidence-and-population-evidence* ## Two Types of Audit Evidence | Evidence Type | What It Proves | Audit Type | Example | |---------------|---------------|------------|---------| | Configuration | Control is designed and implemented | Type I and II | Screenshot of GitHub branch protection requiring 1 reviewer | | Population | Control operated consistently over time | Type II only | 25 random PRs from the audit period, all showing reviewer approval | ## Configuration Evidence Configuration evidence is a snapshot. It shows that at a specific point in time, a control was in place. Think of it as proving the guard rail exists. **Examples:** - Screenshot of MFA settings showing "enforced for all users" - AWS IAM policy JSON showing least-privilege access - GitHub branch protection rules requiring PR reviews - Encryption settings showing AES-256 enabled on your database For SOC 2 Type I, configuration evidence is the primary focus. The auditor checks that controls are *designed* properly. ## Population Evidence Population evidence proves a control worked repeatedly across the audit period. The auditor selects a sample from the full population of events and checks each one. Think of it as proving the guard rail stopped cars all year, not just the day it was installed. **Examples:** - 25 PRs sampled from the audit period, did each have an approved review? - 10 employee terminations, was access revoked within the required timeframe for each? - All onboarded employees, did each complete security training? - 15 incidents, was each responded to according to the IRP? ## Why This Distinction Matters Startups preparing for Type II often focus on configuration evidence (one-time screenshots) and forget that auditors will sample transactions across the entire observation period. If you set up branch protection but bypassed it three times for "urgent hotfixes," those bypasses will show up in the population sample. Plan ahead: maintain your controls consistently during the observation period, and make sure emergency exceptions are documented with justification. --- ### What is the difference between Drata and Screenata? *Keywords: Drata vs Screenata, Drata alternative, Screenata comparison* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-drata-and-screenata* ## How Are Drata and Screenata Different? Drata is a compliance *dashboard*, it connects to AWS, GCP, and Azure, monitors infrastructure configurations, and organizes your policies and evidence in one place. But it doesn't write your policies, doesn't know your application code, and doesn't capture application-level evidence. You still need someone to do that operational work. Screenata is a compliance *operator*, it reads your codebase and cloud setup, generates SOC 2 policies that reference your actual tech stack, and collects the evidence that Drata can't automate. ## Feature Comparison ## When to Choose Drata Drata works well for companies with 50+ employees that already have a security team or compliance lead. If you have someone who knows SOC 2 and can configure the platform, write policies, and manage the audit, Drata gives them a good workspace. ## When to Choose Screenata --- ### What is the main difference between GDPR and CCPA? *Keywords: GDPR vs CCPA, difference between GDPR and CCPA, US equivalent of GDPR, does GDPR apply in the United States* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-gdpr-and-ccpa* ## What is the main difference between GDPR and CCPA? The main difference is **the default**. GDPR requires a lawful basis, such as consent or contract, before personal data is processed at all, and it applies to any organization handling data of people in the EU regardless of size. CCPA lets businesses collect personal information by default and gives California consumers rights to know, delete, correct, and **opt out** of its sale or sharing, and it applies only to for-profit businesses above set thresholds. GDPR is also far more expensive to breach, with fines up to 4% of global annual turnover. ## GDPR and CCPA side by side ## Which one applies to a US SaaS company Below the CCPA revenue threshold, a startup can still be caught by the 100,000 consumers test if it handles a large consumer user base, and it is often caught contractually anyway, because enterprise customers push their own GDPR and CCPA obligations onto vendors through data processing agreements. ## Where they overlap in practice The operational work is largely shared. Both laws expect you to know what personal data you hold and where it flows, to honor access and deletion requests within set deadlines, to secure the data with reasonable measures, and to bind your vendors by contract. A data inventory, a subprocessor list, a documented request-handling procedure, and a security program covering access control and encryption satisfy most of both at once. Neither law is a security framework, and a SOC 2 report does not discharge either. SOC 2 does produce much of the security evidence both laws ask for. For how SOC 2 relates to the legal regimes around it, see [is SOC 2 legally required](/resources/answers/is-soc-2-legally-required). --- ### What is the difference between HITRUST and SOC 2? *Keywords: HITRUST vs SOC 2, difference between HITRUST and SOC 2, is HITRUST better than SOC 2, difference between HITRUST and HIPAA* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-hitrust-and-soc-2* ## What is the difference between HITRUST and SOC 2? **SOC 2 produces an attestation report from a CPA firm, and HITRUST produces a certification from the HITRUST Alliance.** A SOC 2 report is issued by a licensed CPA firm, and the company describes its own controls against the AICPA Trust Services Criteria. A HITRUST certification is issued by the HITRUST Alliance after an authorized external assessor tests the company against fixed requirement statements in the HITRUST CSF. SOC 2 is the default ask across B2B software. HITRUST is requested mostly by large health systems and payers. ## HITRUST and SOC 2 side by side | | SOC 2 | HITRUST | |---|---|---| | What you receive | An attestation report with the auditor's opinion | A certification letter plus an assessment report | | Who issues it | A licensed CPA firm | The HITRUST Alliance, after testing by an authorized external assessor and HITRUST's quality review | | Control set | You define controls against the Trust Services Criteria | Prescriptive requirement statements from the HITRUST CSF | | Size of scope | Varies with the controls you define and the criteria in scope | e1: 44 requirements; i1: 182 requirements; r2: risk-based, tailored to the organization | | Validity | Type II covers a 3 to 12 month period; renewed annually | e1 and i1: one year; r2: two years with an interim assessment | | Typical requester | Enterprise buyers in any industry | Large health systems, payers, and some healthcare partners | | Relation to HIPAA | Can evidence HIPAA security practices; HIPAA can be added to scope | Requirements incorporate HIPAA security provisions | The e1 and i1 counts are from HITRUST CSF version 11. HITRUST updates the CSF regularly, so the exact requirement set depends on the version in force when the assessment starts. ## Which one a healthcare SaaS company needs The order most vendors follow is SOC 2 first, HITRUST when a customer names it. SOC 2 opens enterprise deals in every vertical, including healthcare, and it can be scoped to include HIPAA-relevant controls. HITRUST becomes necessary when a specific health system or payer writes it into the vendor requirements, which is common among the largest hospital networks and less common among clinics, digital health companies, and life sciences buyers. The HITRUST tier matters as much as the choice to pursue it. An e1 covers foundational hygiene and is a quick first step. An i1 is what many health systems accept for moderate-risk vendors. An r2 is the most demanding and the one the largest organizations ask for when a vendor handles significant volumes of PHI. Ask the customer which tier they accept before scoping anything. ## How HIPAA fits with both HIPAA is neither a report nor a certification. It is a federal law, enforced by the HHS Office for Civil Rights, and there is no official HIPAA certification from any government body. A SOC 2 report or a HITRUST certification is evidence that your security practices meet recognized standards, which helps in a customer review and in an OCR inquiry, but neither replaces the obligations HIPAA imposes directly: a risk analysis, business associate agreements, and breach notification. For background on the certification itself, see [what HITRUST is and why hospitals require it](/resources/answers/what-is-hitrust-and-why-do-hospitals-require-it). --- ### What is the difference between ISO 27001 and NIST 800-53? *Keywords: ISO 27001 vs NIST 800-53, difference between ISO 27001 and NIST 800-53, 4 categories of ISO 27001, NIST 800-53 to ISO 27001 mapping* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-iso-27001-and-nist-800-53* ## What is the difference between ISO 27001 and NIST 800-53? **ISO 27001 is a certifiable standard for running a security management system, and NIST 800-53 is a detailed catalog of controls with no certification.** ISO 27001 requires a risk-driven process for running information security and lists 93 reference controls in Annex A, and an accredited certification body can certify you against it. NIST SP 800-53 lists roughly 1,000 controls and enhancements across 20 families, is mandatory for US federal systems, and is used by commercial companies mainly as a reference. ## ISO 27001 and NIST 800-53 side by side | | ISO 27001:2022 | NIST SP 800-53 Rev. 5 | |---|---|---| | Publisher | ISO and IEC, international standards bodies | US National Institute of Standards and Technology | | Type | Management system standard with reference controls | Control catalog | | Size | 93 Annex A controls in 4 themes | Roughly 1,000 controls and enhancements in 20 families | | How controls are chosen | Risk assessment, justified in a Statement of Applicability | Low, moderate, or high baseline, then tailoring | | Certification | Yes, by an accredited certification body, valid three years with annual surveillance audits | No; federal systems receive an authorization to operate | | Who requires it | International and enterprise buyers | US federal agencies and their contractors, and FedRAMP | | Cost of use | The standard must be purchased | Free to download | ## How the structure differs ISO 27001's core is its management clauses, 4 through 10: define scope, assess risk, set objectives, operate controls, measure, audit internally, review, and improve. Annex A is a checklist of controls to consider, and you may exclude controls that do not apply as long as the Statement of Applicability says why. A certification auditor tests the management system as much as the controls. NIST 800-53 starts from the controls. Each control has a statement, discussion, and optional enhancements, and the baselines in SP 800-53B select which ones a system of a given impact level must implement. A single 800-53 control such as AC-2, Account Management, carries more than a dozen enhancements, where ISO 27001 covers the same ground in a few Annex A controls. That detail is why 800-53 is often used as a reference catalog even by organizations that never need it. ## How they map to each other NIST publishes an official mapping between SP 800-53 and ISO 27001, so the two are routinely used together. The mapping is many-to-many: one Annex A control usually corresponds to several 800-53 controls, because 800-53 splits each topic more finely. That granularity is what makes 800-53 useful as a hub. When a company holds SOC 2 and adds ISO 27001 or HIPAA, mapping each framework to one detailed catalog lets a single control test serve all of them, instead of maintaining three overlapping control lists. Screenata uses NIST 800-53 as the hub for SOC 2, ISO 27001, and HIPAA for exactly this reason. For more on the catalog itself, see [what NIST 800-53 is](/resources/answers/what-is-nist-800-53). --- ### What is the difference between SOC 2 Type I and Type II? *Keywords: SOC 2 Type I vs Type II, SOC 2 Type 1 vs Type 2, which SOC 2* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-soc-2-type-i-and-type-ii* ## What Is the Difference? SOC 2 Type I and Type II are two levels of the same audit. Type I checks that your controls are designed correctly at a single point in time. Type II checks that those controls actually worked consistently over a period, typically 3 to 12 months. Think of Type I as a snapshot and Type II as a video. ## Side-by-Side Comparison | Aspect | Type I | Type II | |--------|--------|---------| | What it tests | Control design at a point in time | Control operating effectiveness over a period | | Duration | 4–8 weeks to prepare | 3–12 month observation period + audit | | Cost | Lower (auditor + prep) | Higher (longer engagement) | | Buyer acceptance | Accepted for initial vendor review | Preferred for ongoing relationships | | Evidence required | Point-in-time screenshots and configs | Continuous evidence across the full period | | Typical first step | Yes, most startups start here | Usually follows a Type I | ## Which Should You Get First? Start with Type I. It proves your controls are designed correctly and gives you a report to share with prospects immediately. Then begin your Type II observation period right after, the controls you built for Type I carry forward. Some startups skip Type I and go straight to Type II. This works if you already have mature controls and can wait 3–6 months for the observation period. But if you need a report for an active deal, Type I gets you there faster. ## What Enterprise Buyers Actually Want Most enterprise security teams accept a Type I report for initial vendor approval. They will expect you to produce a Type II report within 12 months. A few large enterprises (banks, healthcare systems) require Type II from the start. Ask your prospect what they need before assuming you need Type II immediately. You may be over-investing. ## The Practical Path 1. Get Type I audit-ready (4–6 weeks) 2. Complete the Type I audit (2–3 weeks) 3. Start your Type II observation period immediately 4. Complete Type II audit after 3–6 months --- ### What is the difference between Vanta and Screenata? *Keywords: Vanta vs Screenata, Vanta alternative, Screenata comparison* *Source: https://screenata.com/resources/answers/what-is-the-difference-between-vanta-and-screenata* ## How Are Vanta and Screenata Different? Vanta is the most popular GRC platform for startups. It connects to your cloud providers, monitors infrastructure configurations, stores policies, and tracks employee security training. But Vanta doesn't write your policies, doesn't understand your application code, and still expects you to bring compliance expertise, either your own or a consultant's. Screenata takes a different approach. Instead of giving you a dashboard to manage compliance yourself, it acts as your AI compliance officer, reading your codebase, generating policies that reference your actual tech stack, and automating evidence collection at the application level. ## Feature Comparison ## The Real Cost Difference ## Which Is Right for You? If you have a dedicated security or compliance person who just needs a monitoring tool, Vanta is a solid choice. If you're a startup founder or CTO going through SOC 2 for the first time without compliance expertise on your team, Screenata was built for that scenario. --- ### What is the minimum viable compliance setup for a pre-seed startup? *Keywords: minimum compliance, pre-seed security, startup security basics* *Source: https://screenata.com/resources/answers/what-is-the-minimum-viable-compliance-setup-for-a-pre-seed-startup* ## The Minimum Viable Compliance Stack You don't need SOC 2 at pre-seed. But you should build security habits that make SOC 2 trivial when you do need it. ### Must-Have (Day 1) ### Should-Have (Month 1-3) | Control | Tool | Cost | |---------|------|------| | Device encryption | FileVault (Mac), BitLocker (Windows) | Free | | Basic access controls | Separate admin/member roles in GitHub and cloud | Free | | Terms of service | Standard template | Free | | Offboarding checklist | Notion/Google Docs template | Free | ### Nice-to-Have (When You Have Budget) ## Why This Matters at Pre-Seed - **Customer trust:** Even early customers appreciate seeing MFA and encrypted data - **Investor confidence:** Security basics show operational maturity - **Future-proofing:** These habits make SOC 2 a 4-week project instead of 4 months - **Data protection:** It's the right thing to do even without compliance requirements ## What You Can Skip - Formal policies (wait until SOC 2) - GRC platforms (way too expensive at this stage) - Compliance consultants (no need yet) - Penetration testing (wait until you have a mature product) - Compliance frameworks of any kind (SOC 2, ISO, HIPAA) ## The Transition Point When your first enterprise prospect says "do you have a SOC 2?", that's when you formalize. Everything you've built at pre-seed (MFA, access controls, code reviews, encryption) becomes the foundation for your SOC 2 program. The gap between "minimum viable compliance" and "SOC 2 ready" is mostly documentation. --- ### What is the NIST Risk Management Framework? *Keywords: NIST risk management framework, NIST RMF, NIST RMF steps, SP 800-37* *Source: https://screenata.com/resources/answers/what-is-the-nist-risk-management-framework* ## What is the NIST Risk Management Framework? The NIST Risk Management Framework is a **seven-step process** for managing security and privacy risk in information systems, defined in **SP 800-37**. It is mandatory for US federal information systems and provides the process that wraps around the NIST 800-53 control catalogue: the RMF is how you decide what to do, and 800-53 is what you choose from. ### The seven steps | Step | What happens | |---|---| | **1. Prepare** | Organisational and system-level groundwork: roles, risk tolerance, strategy | | **2. Categorize** | Classify the system and its information by impact level | | **3. Select** | Choose a control baseline from 800-53 and tailor it | | **4. Implement** | Deploy the controls and document how | | **5. Assess** | Test whether they are implemented correctly and operating as intended | | **6. Authorize** | A senior official accepts the residual risk and authorises operation | | **7. Monitor** | Continuous monitoring of controls, changes, and risk posture | **Prepare** was added in Revision 2. The earlier six steps assumed the organisational groundwork already existed, and in practice it usually did not, which is why programmes stalled at Categorize. ## RMF, 800-53, and CSF are three different things This is the most common confusion in the NIST family. | | What it is | Who it is for | |---|---|---| | **RMF (SP 800-37)** | A seven-step process | Federal systems, mandatory | | **800-53** | A control catalogue | Federal systems, and voluntary crosswalk use | | **Cybersecurity Framework** | Identify, Protect, Detect, Respond, Recover | Any organisation, voluntary | If a commercial company says it "uses NIST", it almost always means the **Cybersecurity Framework**, not the RMF. ## The step that matters most commercially **Step 6, Authorize.** The RMF requires a named senior official to formally accept residual risk before a system operates. Most commercial programmes have no equivalent, and it is the step worth borrowing: a documented decision by someone with the authority to make it, recorded before the risk is live rather than after an incident. That is the same principle as documented risk acceptance in a [risk register](/resources/answers/what-is-a-risk-register), which is the commercial version of the same control. ## Where Screenata sits We use **NIST 800-53 as a crosswalk hub**, mapping SOC 2, HIPAA, ISO 27001, and ISO 42001 onto a shared control set so evidence collected once satisfies several frameworks. That is a use of the catalogue, not of the RMF. **We do not support the RMF, FedRAMP, or FISMA authorisation processes**, which require an authorisation boundary and an authorising official that a commercial compliance platform does not provide. --- ### What is the total cost of SOC 2 including platform, consultant, and auditor? *Keywords: SOC 2 total cost, SOC 2 all-in cost, SOC 2 hidden costs* *Source: https://screenata.com/resources/answers/what-is-the-total-cost-of-soc-2* ## What Is the Real All-In Cost? Most startups underestimate SOC 2 cost because they only price the auditor. The auditor fee is typically the smallest line item. The real cost includes the platform, the human expertise to configure it, and the engineering time to collect evidence. ## Year One Cost Comparison ## Hidden Costs Most Founders Miss ## Why the Traditional Path Is Expensive The traditional SOC 2 stack was designed for mid-market companies with compliance teams. Drata and Vanta provide dashboards and integrations, but they assume you have someone who knows how to configure controls, write policies, and map evidence. Most startups hire a consultant to fill that gap, doubling the cost. ## The Alternative --- ### What should a CTO prioritize before the SOC 2 audit? *Keywords: CTO SOC 2 priorities, technical SOC 2 prep, engineering SOC 2* *Source: https://screenata.com/resources/answers/what-should-a-cto-prioritize-before-the-soc-2-audit* ## CTO's SOC 2 Priority List ### Priority 1: Quick Wins (Day 1-2) | Action | Time | Impact | |--------|------|--------| | Enforce MFA on Google Workspace | 30 min | Eliminates top access control finding | | Enable GitHub branch protection on main | 15 min | Proves change management controls | | Require GitHub org-level 2FA | 15 min | Secures code repository access | | Block public S3 access (if using AWS) | 15 min | Prevents data exposure | | Enable CloudTrail | 30 min | Creates audit logging | ### Priority 2: Access Controls (Week 1) - **Restrict admin access.** Review who has Owner/Admin roles on GitHub, AWS, and Google Workspace. Limit to CTO + 1-2 senior engineers. - **Remove former employee accounts.** Audit all systems for stale accounts. - **Document the permission model.** Write down which roles exist and what each can access. ### Priority 3: Infrastructure Controls (Week 2) - **Deploy MDM** (Kandji, Mosyle) on all company devices - **Verify encryption** on databases and storage services - **Enable automated backups** with documented retention periods - **Set up basic monitoring**, CloudWatch alarms, Sentry error tracking, PagerDuty ### Priority 4: Documentation (Week 3-4) - **Write the system description.** Name your tech stack specifically, "Next.js on Vercel, PostgreSQL on Supabase, GitHub Actions CI/CD." - **Review or write the change management policy.** Describe your actual PR → review → merge → deploy workflow. - **Draft the access control policy.** Document your current RBAC model. ## What Not to Waste Time On - Building custom compliance dashboards - Implementing SIEM tools (not required for most startups) - Hiring a security engineer before the audit - Over-engineering access controls beyond what's needed ## The CTO's Ongoing Role During the observation period (Type II), the CTO is typically responsible for: - Quarterly access reviews - Approving policy updates - Responding to audit evidence requests - Maintaining branch protection and access controls --- ### What should I read to prepare for SOC 2 as a founder? *Keywords: SOC 2 reading list, SOC 2 for founders, learn SOC 2* *Source: https://screenata.com/resources/answers/what-should-i-read-to-prepare-for-soc-2-as-a-founder* ## The Essential Reading List ### 1. AICPA Trust Services Criteria (Free) The official criteria document defines what SOC 2 evaluates. Read the Security category (CC1-CC9), that's the baseline for every audit. Skip the other categories unless they're in your scope. **Time:** 2 hours ### 2. Your Auditor's Evidence Request List Ask your auditor (or prospective auditor) for their standard evidence request template. This tells you exactly what they'll ask for, specific to their methodology. **Time:** 1 hour to review ### 3. A SOC 2 Startup Guide Look for guides written specifically for startups, not enterprise compliance teams. The best ones cover: which TSC to pick, how to scope, what policies to write, and what evidence to collect. **Time:** 2-3 hours ## What You Can Skip | Resource | Why You Can Skip It | |----------|-------------------| | SSAE 18 / AT-C 205 (audit standards) | Written for auditors, not auditees | | 200-page SOC 2 compliance handbooks | Too detailed for a first-time audit | | NIST Cybersecurity Framework | Useful but separate from SOC 2, don't confuse the two | | ISO 27001 documentation | Different framework, different audit | ## What to Learn by Doing (Not Reading) Some things are better learned by doing than reading: - **Run a readiness assessment.** Walk through the TSC criteria and check your systems against each one. - **Write one policy.** Start with your change management policy, it's the easiest to write because it describes your existing GitHub workflow. - **Talk to an auditor.** A 30-minute pre-engagement call teaches more than a 100-page guide. ## The Minimum Knowledge for a Founder You don't need to become a compliance expert. You need to know: 1. Which TSC criteria are in your scope 2. What your seven core policy documents should say 3. What evidence your auditor will ask for 4. How to run a quarterly access review Everything else can be handled by your auditor's guidance or by an AI compliance tool like Screenata. --- ### What SOC 2 evidence do I need for a GitHub-based CI/CD pipeline? *Keywords: GitHub Actions SOC 2, CI/CD SOC 2 evidence, GitHub compliance* *Source: https://screenata.com/resources/answers/what-soc-2-evidence-do-i-need-for-a-github-based-cicd-pipeline* ## Evidence for GitHub CI/CD GitHub Actions with branch protection creates a natural SOC 2 audit trail. Here's everything you need: ## Configuration Evidence | Item | Where to Find It | SOC 2 Control | |------|-----------------|---------------| | Branch protection rules | Settings → Branches → main | CC8.1 | | Required reviewers | Branch protection → Require PR reviews | CC8.1 | | Required status checks | Branch protection → Require status checks | CC8.1 | | Force push prevention | Branch protection → Do not allow force pushes | CC8.1 | | GitHub Actions workflows | .github/workflows/*.yml files | CC8.1 | | Organization 2FA | Settings → Authentication security | CC6.1 | | Member permissions | Settings → Member privileges | CC6.1 | ## Population Evidence (Type II) Auditors will sample 20-25 merged PRs from the audit period. Each should show: 1. **PR description**, What changed and why 2. **Reviewer approval**, At least one approving review from someone other than the author 3. **CI checks passing**, GitHub Actions status checks green 4. **Merge to main**, The PR was merged (not committed directly) ## GitHub Actions Workflow Best Practices Your GitHub Actions workflow should include at minimum: - Linting or type checking - Unit tests - Build verification Document the workflow file itself as evidence, it shows what checks run on every PR. ## Common Gaps - **Admin bypass enabled:** Branch protection allows admins to bypass rules. Disable this. - **No CI on PRs:** GitHub Actions only runs on push to main, not on PR. Configure it to run on `pull_request` events. - **Missing test coverage:** Having a CI workflow that only builds (no tests) weakens the evidence. - **Direct commits:** Any commits directly to main without a PR will show up in audit sampling. ## Emergency Change Process Document a process for hotfixes that bypass normal CI/CD: 1. Direct deploy with documented justification 2. Post-deployment PR created within 24 hours 3. Retroactive review and approval 4. Incident documented in your change log --- ### What SOC 2 evidence do I need for a multi-tenant SaaS app? *Keywords: multi-tenant SOC 2, SaaS SOC 2 evidence, tenant isolation* *Source: https://screenata.com/resources/answers/what-soc-2-evidence-do-i-need-for-a-multi-tenant-saas-app* ## Why Multi-Tenancy Matters for SOC 2 Multi-tenant architectures serve multiple customers from shared infrastructure. Auditors need to verify that tenant isolation is enforced, that Customer A cannot see Customer B's data, even if they share the same database, application servers, and API endpoints. ## Evidence by Isolation Model | Isolation Model | Evidence Required | |----------------|------------------| | Separate databases per tenant | Database list showing per-customer DBs, connection routing logic | | Shared database, separate schemas | Schema list, middleware ensuring correct schema selection | | Shared database, tenant ID column | Query scoping logic, middleware injecting tenant filters, authorization tests | | Row-level security (RLS) | RLS policy definitions, proof that policies are enforced | ## Key Evidence to Provide ### 1. Tenant Isolation in Code Show how your application ensures queries are scoped to the authenticated tenant: - Middleware or context that sets the current tenant - Database queries filtered by tenant ID - API routes that verify tenant ownership before returning data ### 2. Authorization Checks - Evidence that API endpoints check the requesting user belongs to the target tenant - Screenshot or code showing cross-tenant access attempts are blocked ### 3. Testing - Test results showing cross-tenant data leakage is prevented - Security review of shared endpoints (search, reporting, exports) for tenant boundary enforcement ### 4. Infrastructure Isolation - Network security: are tenant workloads isolated at the network level? - Encryption: is data encrypted per-tenant or with shared keys? - Backups: can you restore a single tenant's data? ## Common Findings - **Shared admin endpoints:** Admin APIs that don't check tenant scope, allowing admin users to query across tenants - **Search leakage:** Full-text search returning results from other tenants - **File storage:** S3 bucket paths not enforcing tenant boundaries - **Logging:** Application logs containing data from multiple tenants without access controls on the logs themselves ## What Auditors Ask Expect the auditor to ask: "Show me how you prevent one customer from accessing another customer's data." Have a clear answer, code, configuration, and test evidence, ready. --- ### What SOC 2 evidence is needed for AWS infrastructure? *Keywords: AWS SOC 2 evidence, AWS compliance checklist, cloud infrastructure compliance* *Source: https://screenata.com/resources/answers/what-soc-2-evidence-is-needed-for-aws-infrastructure* ## AWS Evidence by Service | AWS Service | SOC 2 Evidence | Control | |-------------|---------------|---------| | IAM | User list, MFA status, password policy, role policies | CC6.1 | | S3 | Public access block, encryption, bucket policies | CC6.7 | | RDS/Aurora | Encryption at rest, backup config, security groups | CC6.7, A1.2 | | CloudTrail | Multi-region trail enabled, log file validation | CC7.2 | | CloudWatch | Alarms for critical metrics, SNS notifications | CC7.2 | | VPC | Security group rules, NACL rules, flow logs | CC6.6 | | KMS | Key management policies, rotation settings | CC6.1 | ## Priority Order for Startups Not every AWS service needs evidence. Focus on: 1. **IAM** (required), Root account MFA, user MFA, least-privilege policies 2. **CloudTrail** (required), Proves you have audit logging 3. **Your database** (required), Encryption and access restrictions 4. **S3** (if you use it), Public access blocks, encryption 5. **Security groups** (required), Network access controls ## Inherited Controls from AWS AWS has its own SOC 2 Type II report covering physical security, hardware management, and network infrastructure. You can reference this in your system description. Your auditor tests *your* configuration of AWS services, not AWS's underlying infrastructure. ## Quick Wins - **Enable MFA on root account.** This takes 5 minutes and is always tested. - **Turn on CloudTrail.** Enable a multi-region trail with log file validation. - **Block public S3 access.** Enable the account-level public access block. - **Review security groups.** Remove any `0.0.0.0/0` inbound rules that aren't necessary. - **Enable RDS encryption.** If not already enabled, this may require creating a new encrypted instance and migrating. ## Evidence Collection Tips - Use AWS Config for continuous compliance monitoring if your budget allows - Screenshot the console rather than exporting JSON, auditors prefer visual evidence - Run AWS Trusted Advisor to catch common misconfigurations before the audit --- ### When should a startup NOT pursue SOC 2? *Keywords: SOC 2 not needed, skip SOC 2, SOC 2 premature, SOC 2 too early* *Source: https://screenata.com/resources/answers/when-should-a-startup-not-pursue-soc-2* ## When SOC 2 Doesn't Make Sense SOC 2 is a business decision, not a technical one. The question isn't "should we be secure?" (yes, always) but "should we pay for a formal SOC 2 report right now?" ### You Should Wait If: Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ### You Should Pursue SOC 2 If: | Situation | Why Now | |-----------|---------| | Enterprise deal blocked by "send us your SOC 2" | Direct revenue impact | | Multiple prospects asking about compliance | Pattern of demand | | Handling sensitive customer data | Ethical and legal obligation to prove security | | Competitors already have SOC 2 | Competitive disadvantage without it | | Planning a fundraise | Investors in B2B SaaS increasingly expect compliance readiness | ## Alternatives While You Wait You can demonstrate security without a SOC 2 report: - **Trust page** on your website describing your security practices - **Security questionnaire responses** (manual but free) - **Basic security practices** (MFA, encryption, access controls) documented publicly - **Vendor security assessments**, answer customer questionnaires directly ## The Right Trigger Start SOC 2 when the first enterprise deal gets blocked or when three prospects ask "do you have a SOC 2?" in the same quarter. That's your signal that SOC 2 will pay for itself through closed revenue. --- ### Which compliance framework should a startup get after SOC 2? *Keywords: compliance after SOC 2, next framework, ISO or HIPAA after SOC 2* *Source: https://screenata.com/resources/answers/which-compliance-framework-should-a-startup-get-after-soc-2* ## Choose Based on Customer Demand | Your Customers | Next Framework | Why | |---------------|---------------|-----| | International companies | ISO 27001 | Required by EU/UK/APAC buyers | | Healthcare providers | HIPAA + possibly HITRUST | Legal requirement for PHI | | Financial services | PCI DSS or SOC 2 + financial criteria | Payment/financial data requirements | | Government agencies | FedRAMP or CMMC | Required for government contracts | | General enterprise (US) | SOC 2 Type II renewal | Keep your report current | ## Framework Comparison After SOC 2 ## The "Don't Over-Certify" Rule Each framework has ongoing costs, annual audits, certificate renewals, evidence collection, and policy updates. Don't pursue frameworks speculatively. **The test:** Has a customer or prospect specifically asked for this framework in the last quarter? If yes, pursue it. If no, wait. ## The Typical Startup Path 1. **Year 1:** SOC 2 Type I → SOC 2 Type II 2. **Year 2:** Add ISO 27001 if international demand, or HIPAA if healthcare demand 3. **Year 3+:** HITRUST, PCI DSS, or FedRAMP based on market requirements ## Evidence Reuse The good news: 60-80% of your SOC 2 evidence and controls reuse across frameworks. Each additional framework gets cheaper and faster after the first. --- ### Which is better, NIST or CIS? *Keywords: NIST vs CIS, NIST CSF 2.0 vs CIS Controls, CIS Controls v8.1, cybersecurity framework comparison* *Source: https://screenata.com/resources/answers/which-is-better-nist-or-cis* ## Which is better, NIST or CIS? Neither is better, because they are not the same kind of thing. NIST CSF 2.0 is a risk-management framework: six functions that help an organization decide what matters and govern its security program. The CIS Controls v8.1 are a prioritized checklist: 18 control families broken into concrete safeguards, ordered so a team knows what to do first. The practical question is which one fits your situation, and for most teams the answer is CIS for execution, NIST for governance, and often both. ## What each one actually is "NIST" here means the NIST Cybersecurity Framework (CSF), version 2.0, published by the US National Institute of Standards and Technology in February 2024. It is not the same as NIST SP 800-53, the much larger control catalog used by US federal agencies, and conflating the two is the most common source of confusion in this comparison. CSF 2.0 organizes security into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. It deliberately does not tell you which safeguards to implement; it gives you a structure for deciding. The CIS Controls, published by the Center for Internet Security, take the opposite approach. Version 8.1 defines 18 controls containing 153 specific safeguards, ranked by how much attack surface they remove. The safeguards are grouped into three implementation groups: IG1 (56 safeguards of basic cyber hygiene for small organizations), IG2 (adds safeguards for teams with dedicated IT staff), and IG3 (the full set, for organizations handling sensitive data or facing targeted attacks). Both documents are free to download. ## Side by side | | NIST CSF 2.0 | CIS Controls v8.1 | |---|---|---| | Type | Risk-management framework | Prioritized safeguard checklist | | Structure | 6 functions, with categories and subcategories | 18 controls, 153 safeguards, 3 implementation groups | | Tells you what to do first | No, you prioritize based on your own risk | Yes, IG1 is the explicit starting point | | Best fit | Organizations that need governance and a common vocabulary | Teams that want an ordered to-do list | | Certification | None, self-assessed | None, self-assessed | | Cost | Free | Free | Note the certification row: neither NIST CSF nor CIS Controls has an accredited certification. You can assert alignment, and assessors can attest to it, but there is no NIST or CIS certificate equivalent to an ISO 27001 certificate or a SOC 2 report. ## How to choose Pick CIS Controls when you have a small team, no security hire, and you want to know what to do on Monday. IG1 is designed to be achievable without a risk program: inventory your assets, manage accounts, patch, back up, train people. Pick NIST CSF when the pressure is organizational rather than technical: a board asking how security is governed, a cyber insurer or enterprise customer asking you to describe your posture in framework terms, or a US government-adjacent market where NIST vocabulary is the default. Pick both when you outgrow a checklist. A common pattern is CIS safeguards as the implementation layer inside a NIST CSF structure, since CIS publishes official mappings between the two. ## Where SOC 2 fits Neither framework is required for SOC 2, and SOC 2 does not replace either. The AICPA Trust Services Criteria define what a SOC 2 audit tests, and both NIST CSF and CIS Controls map to those criteria. Teams that implement CIS IG1 or align to NIST CSF typically find that most of the same controls satisfy SOC 2 evidence requests. If customers are asking for proof rather than a framework name, a [SOC 2 report](/solutions/soc-2) is usually what they mean. --- ### Which SOC 2 auditor should a startup choose? *Keywords: SOC 2 auditor for startups, best SOC 2 auditors, cheap SOC 2 auditor* *Source: https://screenata.com/resources/answers/which-soc-2-auditor-should-a-startup-choose* ## What Kind of Auditor Should a Startup Use? A boutique CPA firm that specializes in SOC 2 for technology companies. These firms understand cloud-native infrastructure, work with startups regularly, and price their engagements for startup budgets. They deliver the same SOC 2 report as a Big 4 firm at 50–70% less. ## Comparison of Auditor Types ## How to Evaluate a Boutique Firm Ask these questions before signing: 1. How many SOC 2 audits do you complete per year? (Look for 50+) 2. What percentage of your clients are under 50 employees? 3. Can you share references from SaaS companies similar to ours? 4. What is your fixed fee for Type I, Security scope only? 5. What is your timeline from engagement to report? 6. Are you comfortable with our tech stack (name your cloud provider and tools)? ## Firms Worth Considering Look for firms that advertise SOC 2 for startups. Some well-known options in the startup space include Johanson Group, Prescient Assurance, Sensiba, and Barr Advisory. Your compliance tool vendor may also have auditor partnerships with negotiated rates. ## Does the Auditor Brand Matter? Rarely. Enterprise buyers care about the report content and the auditor's opinion, not the firm's brand. A clean, unqualified opinion from a boutique firm carries the same weight as one from Deloitte. The only exception is if a specific buyer contractually requires a Top 10 firm, which is uncommon. --- ### Which SOC certification is best? *Keywords: which SOC certification is best, SOC 1 vs SOC 2 vs SOC 3, SOC 2 Type I vs Type II, SOC report comparison* *Source: https://screenata.com/resources/answers/which-soc-certification-is-best* ## Which SOC certification is best? For most software companies, SOC 2. It is the report customers request in SaaS procurement, and it covers the security controls a buyer cares about. SOC 1 serves a different audience: your customers' financial-statement auditors. SOC 3 is a public summary of a SOC 2 with the detail removed. And strictly speaking, none of these is a certification. They are attestation reports issued by a licensed CPA firm, so "best" depends entirely on who is asking you for one. ### SOC 1 vs SOC 2 vs SOC 3 The decision rule is short. If your service sits inside your customers' financial reporting, you will be asked for SOC 1. If you sell software and a security questionnaire started this search, the answer is SOC 2. ## They are attestations, not certifications There is no SOC certificate and no SOC certifying body. A CPA firm examines your controls and issues an attestation report containing its opinion. Vendors say "SOC 2 certified" as shorthand and buyers accept the phrase, but what changes hands is a report, usually shared under NDA. When a questionnaire asks for your "SOC 2 certificate," the correct artifact to send is the report itself, or the SOC 3 if you want something you can post publicly. ## Type I vs Type II inside SOC 2 The Type I and Type II question is where "which is best" gets a firmer answer. A **Type I** report describes your controls and evaluates their design as of a single date. It is faster and cheaper, and it is a reasonable first report for a company that needs something to show a prospect this quarter. A **Type II** report tests whether those controls operated effectively over an observation period, commonly 3 to 12 months. Because it proves operation rather than intent, it is the report enterprise buyers and contracts actually specify. The common path is Type I first, then a Type II covering the following observation period. ## Where SOC 3 fits A SOC 3 exists for marketing. It carries the auditor's opinion from a SOC 2 Type II examination but strips the system description and test detail, so it can be handed to anyone without an NDA. It cannot substitute for a SOC 2 in a security review, because the reviewer wants the detail the SOC 3 omits. ## Where Screenata fits --- ### Which tool is best for vulnerability scanning? *Keywords: best vulnerability scanning tool, vulnerability scanner comparison, Nessus vs OpenVAS vs Qualys, vulnerability scanning for SOC 2* *Source: https://screenata.com/resources/answers/which-tool-is-best-for-vulnerability-scanning* ## Which tool is best for vulnerability scanning? There is no single best vulnerability scanner. Nessus is the industry standard for network and host scanning, Qualys VMDR and Rapid7 InsightVM dominate enterprise fleets, and OpenVAS is the main open source option. For a startup proving SOC 2, the honest answer is usually none of those: a cloud-native scanner plus dependency scanning covers most of what an auditor will ask about, at a fraction of the cost. ## Two different things get called vulnerability scanning People conflate two distinct categories, and the right tool depends on which one you mean. **Infrastructure scanning** probes hosts, networks, and cloud resources for known vulnerabilities, misconfigurations, and missing patches. Nessus, Qualys, Rapid7, OpenVAS, and the cloud-native scanners live here. **Dependency and code scanning** checks the open source packages and code in your repositories for known CVEs. Snyk and GitHub Dependabot live here. If your product is a SaaS application, this category often surfaces more of your real exposure than a network scan does, because your attack surface is mostly your application and its dependencies rather than a fleet of servers. A vulnerability management program for a modern cloud company normally needs one tool from each category. ## The main options | Tool | Category | Best for | Pricing model | |---|---|---|---| | Nessus (Tenable) | Infrastructure scanner | Teams that want the de facto standard | Commercial, annual license | | Qualys VMDR | Infrastructure scanner | Large enterprise asset fleets | Commercial, per-asset subscription | | Rapid7 InsightVM | Infrastructure scanner | Enterprises wanting risk-based prioritization | Commercial, per-asset subscription | | OpenVAS (Greenbone) | Infrastructure scanner | Budget-constrained teams comfortable self-hosting | Open source; commercial editions exist | | Intruder | SaaS scanner | Startups that want scanning with minimal setup | Commercial SaaS tiers | | AWS Inspector | Cloud-native scanner | Workloads running on AWS | Usage-based, billed with AWS | | Microsoft Defender for Cloud | Cloud-native scanner | Workloads running on Azure | Per-resource subscription | | Snyk | Dependency and code scanner | Application and container dependencies | Free tier; commercial plans | | GitHub Dependabot | Dependency scanner | Anyone already on GitHub | Free with GitHub | ## The best answer for a startup proving SOC 2 Auditors ask for a documented vulnerability management process with regular scans and remediation tracking. They do not ask for a specific brand. That changes the calculus: an AWS-hosted startup that turns on AWS Inspector and Dependabot has continuous scanning across infrastructure and dependencies for close to nothing, while a Nessus license adds cost without adding anything an auditor will credit. The commercial scanners earn their price when you have what they were built for: large mixed fleets, on-premise networks, compliance regimes that mandate authenticated scanning, or a security team that lives in the tooling. A 15-person SaaS company has none of that. ## What auditors actually check For SOC 2, the evidence requests around vulnerability management are consistent across audit firms: - **Cadence.** Scans on a defined schedule. Quarterly is the common minimum; monthly or continuous is better and increasingly the norm for cloud-native setups. - **Severity SLAs.** A written policy stating how fast each severity gets fixed. A typical policy commits to remediating critical findings within 15 days and high findings within 30 days. - **Remediation records.** Proof that findings were tracked to closure, or formally risk-accepted with a reason and an owner. The scanner is the easy part. The part that fails audits is the paper trail connecting scan output to fixes. Screenata tracks scan reports and remediation records as evidence inside a [SOC 2 program](/solutions/soc-2); it does not run scans itself, and it is not a replacement for any tool in the table above. --- ### Who needs to comply with NYDFS cybersecurity regulation? *Keywords: NYDFS cybersecurity regulation, 23 NYCRR Part 500, who must comply with NYDFS, NYDFS covered entity, NYDFS third party service provider* *Source: https://screenata.com/resources/answers/who-needs-to-comply-with-nydfs* ## Who needs to comply with NYDFS cybersecurity regulation? The NYDFS Cybersecurity Regulation, formally 23 NYCRR Part 500, applies to "covered entities": any organization operating under, or required to operate under, a license, registration, or charter under New York's Banking Law, Insurance Law, or Financial Services Law. In practice that means banks, trust companies, insurance companies and licensed insurance agents and brokers, mortgage lenders and servicers, money transmitters, check cashers, virtual currency businesses licensed under the BitLicense regime, and other licensed lenders doing business in New York. If NYDFS licenses you, Part 500 covers you, regardless of where you are headquartered. Disambiguation up front: "NYDFS compliance" in a search almost always means this cybersecurity regulation, first effective in 2017 and substantially amended in November 2023, and not the department's other supervisory rules. And the regulation is entity-based, not data-based: unlike GDPR or state privacy laws, it attaches to holding a New York financial license, not to processing New Yorkers' data. ## The four positions you can be in | Position | Who falls here | What applies | |---|---|---| | Standard covered entity | NY-licensed banks, insurers, mortgage firms, money transmitters, licensed lenders | Full Part 500: cybersecurity program and policy, CISO, risk assessments, MFA, encryption, incident reporting to NYDFS within 72 hours, annual certification | | Limited-exemption entity | Small covered entities, generally fewer than 20 employees (counting affiliates) or below revenue and asset thresholds set in section 500.19 | Still covered and still must file, but exempt from several requirements such as the CISO designation and some technical mandates | | Class A company | The largest covered entities, defined by NY revenue combined with total revenue or headcount over 2,000, counting affiliates | Everything above plus more: independent audits, enhanced monitoring, stronger access and password controls | | Third-party service provider | Vendors, including SaaS companies, with access to a covered entity's systems or nonpublic information | Not directly regulated, but contractually held to the covered entity's 500.11 vendor security requirements | Three points worth stressing. First, exempt does not mean out of scope: limited-exemption entities must still run a cybersecurity program and file with NYDFS, they just skip parts of the rule, and they must file a notice claiming the exemption. Second, the thresholds moved in the 2023 amendment (the employee cutoff rose from 10 to 20, and Class A was newly created), so guidance written before 2023 understates who is exempt and omits Class A entirely. Third, the amendment's requirements phased in over roughly two years, with the final tranche, including expanded MFA coverage, landing in late 2025, which is why enforcement attention is high right now. ## How the regulation reaches companies that are not covered Most startups asking this question are not covered entities. They are vendors to one. Section 500.11 requires every covered entity to maintain a third-party service provider security policy: due diligence before onboarding a vendor, minimum cybersecurity practices the vendor must meet, and periodic reassessment. The covered entity is on the hook to NYDFS for doing this, so it pushes the obligation downstream through security questionnaires, contract security addenda, and requests for audit reports. That is the practical answer for a SaaS company: NYDFS will never examine you, but your bank and insurance customers must examine you, on a recurring basis, and their questionnaires track Part 500's themes: access controls and MFA, encryption of nonpublic information, incident response and notification commitments, and personnel security. ## Where Screenata fits Screenata does not sell an NYDFS compliance program, and a covered entity's own Part 500 obligations, certifications, and filings sit with its compliance and legal teams. What Screenata covers is the vendor side of the equation: a [SOC 2](/solutions/soc-2), ISO 27001, or HIPAA program that produces the evidence a covered entity's 500.11 review asks for, with about 70% of evidence collected automatically and delivered as cryptographically signed evidence packs. If your first NYDFS-flavored questionnaire just arrived from a bank or insurer prospect, that questionnaire, not Part 500 itself, is the requirement you actually have to satisfy. --- ### Why are AI-generated SOC 2 policies better than templates? *Keywords: SOC 2 policy templates vs AI, codebase-aware policies, AI compliance advantage* *Source: https://screenata.com/resources/answers/why-are-ai-generated-soc-2-policies-better-than-templates* ## Why Templates Fall Short SOC 2 policy templates are generic by design. They use placeholders like "[Company Name]" and "[Insert authentication method]", and hope you fill in the blanks correctly. The problem is that most startups don't know what to put in those blanks, and the template doesn't know enough about your systems to tell you. A template might say "The company enforces role-based access control." But if your application actually uses a permissions system built on Clerk with custom roles, your auditor will want to see that specificity. Generic language raises follow-up questions. Specific language doesn't. ## Template vs. AI-Generated Policy | Aspect | Template Policy | AI-Generated Policy | |--------|----------------|-------------------| | Authentication description | "Multi-factor authentication is enforced" | "MFA is enforced via Google Workspace for all employees and via NextAuth with TOTP for application access" | | Change management | "All changes follow an approval process" | "All code changes require a GitHub PR with at least one reviewer approval before merging to main via Vercel deployment" | | Data encryption | "Data is encrypted at rest and in transit" | "Data at rest is encrypted using AES-256 in Supabase PostgreSQL; in transit via TLS 1.3 enforced at the Vercel edge" | | Accuracy | Requires manual verification | Verified against actual code | ## Why Auditors Prefer Specificity Auditors test controls by comparing what your policies say against what your systems actually do. If your policy says "approved changes only," the auditor checks your GitHub branch protection settings. If the policy is generic, the auditor has to ask more questions to understand what you actually mean. Specific, accurate policies speed up the audit and reduce the chance of findings. ## Where Screenata Fits Screenata reads your GitHub repos and cloud accounts to generate policies that reference your exact tech stack. Instead of starting with a template and trying to make it match, Screenata starts with your systems and writes policies that are accurate from day one. --- ### Why can AI automate the compliance consultant's prep work but not the auditor's role? *Keywords: AI compliance prep, AI not auditor, SOC 2 auditor required* *Source: https://screenata.com/resources/answers/why-can-ai-replace-the-compliance-consultant-but-not-the-auditor* ## Two Different Roles | Role | What They Do | Why They Exist | |------|-------------|---------------| | Consultant (vCISO) | Prepares you for the audit, policies, evidence, gap remediation, and advises on strategy | You hire them for expertise and judgment | | Auditor (CPA firm) | Tests your controls and issues the SOC 2 report | Required by AICPA standards | ## Why AI Automates the Consultant's Prep Work Much of a consultant's engagement is repeatable operational work, knowledge applied to your systems in a predictable way: - They learn about your tech stack → AI reads your codebase directly - They write policies from interviews → AI drafts policies from code analysis - They identify gaps → AI maps your systems to TSC criteria - They guide evidence collection → AI collects evidence automatically Every one of those is knowledge work AI can do faster and more comprehensively, because it can read your entire codebase in minutes. What AI doesn't replace is the consultant's judgment, risk-acceptance calls, unusual scope, board and auditor relationships. Automating the operational layer is exactly why many consultants now use AI to serve more clients. ## Why AI Cannot Replace the Auditor SOC 2 reports are attestation engagements governed by AICPA standards (AT-C 205). Only a licensed CPA firm can: 1. **Provide independent attestation.** The auditor must be independent of your organization. No tool you purchase can be "independent" in this sense. 2. **Issue the SOC 2 report.** The report is a formal document with the CPA firm's opinion. Only a licensed firm can issue it. 3. **Apply professional judgment.** Auditors determine materiality, evaluate exceptions, and decide on the opinion type. These require professional judgment protected by audit standards. 4. **Bear legal responsibility.** The CPA firm is legally liable for the accuracy of their opinion. Software can't bear this liability. ## The New Relationship AI compresses the operational-prep cost while the auditor cost remains, because it must. The consultant's advisory role stays valuable; the grunt work just moves to software. --- ### Why did my SOC 2 report fail an enterprise security review? *Keywords: SOC 2 report rejected, SOC 2 security review, enterprise security review SOC 2, vendor security review failed, SOC 2 report exceptions, what security teams look for in a SOC 2 report* *Source: https://screenata.com/resources/answers/why-did-my-soc-2-report-fail-an-enterprise-security-review* ## What Does an Enterprise Security Team Actually Read? A SOC 2 report is not a certificate, and enterprise reviewers do not treat it as one. They read it the way an auditor would: the opinion, the system description, the list of controls, the tests the auditor performed on each, and the results. The question they are answering is narrower than "does this vendor have SOC 2." It is "does this report give us evidence that the controls we depend on work, for the system we are buying." If a customer only needs a report on file, most of what follows never comes up. When a buyer's security team reads the report line by line, it does. ## The Common Reasons a Report Fails | What the reviewer found | Why it fails | What fixes it | |---|---|---| | A Type I where the buyer requires a Type II | Type I shows controls were designed at a point in time, not that they operated over a period | A Type II covering an observation window | | A short or stale period | A brief Type II window gives thin evidence, and a period that ended long ago says little about today | A longer window next cycle; a [bridge letter](/resources/answers/what-is-a-soc-2-bridge-letter-and-when-do-you-need-one) for a gap of a few months | | Scope that leaves out the product | The system description covers a different environment, or carves out the subservice organizations that run it | A system description that matches what the buyer uses, with carved-out vendors' own reports on hand | | Exceptions on controls the buyer cares about | Access removal, change management, and logging exceptions are the ones reviewers stop on | Fix the control, then show dated evidence it has held since | | Tests that relied on inquiry | Section 4 shows the auditor asked or read a policy instead of inspecting samples | Controls that produce evidence an auditor can sample | | Policies that promise more than the controls do | A policy commits to quarterly reviews or a response time the evidence does not show | Policies written from what you actually run | | An auditor the reviewer does not trust | An unfamiliar firm with no published peer review, or one chosen and paid through the platform vendor that produced the evidence | An independent firm you choose, with a published AICPA peer review | The last row is the one you control before the audit starts. In April 2026 the AICPA named bundled fee-setting, tool-driven deadlines, and referral concentration as threats to auditor independence. The question worth asking any vendor before you sign is simple: does your platform vendor also provide your auditor? For the difference between the two report types, see [SOC 2 Type I vs Type II](/resources/answers/what-is-the-difference-between-soc-2-type-i-and-type-ii). ## What Should You Do Now? ## How Do You Avoid It Next Time? Several of these reasons trace back to remediation that was squeezed to fit the audit budget: exceptions, thin testing, and policies that promise more than the controls do. Budget the two separately, as the guide to [budgeting the SOC 2 audit and remediation](/resources/answers/should-i-budget-the-soc-2-audit-and-remediation-separately) lays out, and do the control work before fieldwork rather than after a buyer finds the gap. Screenata is built for the part reviewers read closely. Policies are written from a scan of your real infrastructure, and hard commitments the evidence cannot back are flagged before they reach the auditor. Every artifact is mapped to a control, dated, and signed, so any firm can verify it outside the platform. Screenata does not sell the audit: you choose and pay the firm, which gives you a clean answer if a reviewer asks who picked your auditor. --- ### Why do AI-written policies beat template-based policies for SOC 2? *Keywords: AI vs template SOC 2, codebase-aware policies advantage, Screenata vs templates* *Source: https://screenata.com/resources/answers/why-do-ai-written-policies-beat-template-based-policies-for-soc-2* ## The Template Problem Templates are designed to fit any company. This universality is their biggest flaw, they fit no company perfectly. You download a "SOC 2 Access Control Policy Template," fill in your company name, and hope the remaining generic language is close enough. It usually isn't. ## Where AI-Written Policies Win | Dimension | Template | AI-Written (Codebase-Aware) | |-----------|----------|---------------------------| | Accuracy | Generic, may claim controls you don't have | Specific, describes what actually exists | | Customization effort | 4-8 hours per policy to customize | 30 minutes to review and approve | | System references | "[Insert provider]" placeholders | "Supabase PostgreSQL with AES-256" | | Audit risk | High, mismatches between policy and reality | Low, policy generated from reality | | Maintenance | Manual updates when systems change | AI detects changes, flags updates | ## Real Examples **Access Control Policy, Template:** > "The organization uses a centralized identity management solution to provision and deprovision user access. Multi-factor authentication is required for all users accessing production systems." **Access Control Policy, AI-Written:** > "Employee access is managed through Google Workspace with SAML SSO. MFA is enforced for all accounts using hardware security keys or TOTP apps. Application user authentication uses Clerk with email/password and optional TOTP. The CTO provisions and deprovisions access within 4 hours of hire/termination. Quarterly access reviews are conducted across Google Workspace, GitHub, AWS, and Supabase." The AI version is testable. The auditor can verify every statement. ## The Hidden Cost of Templates Template users often discover gaps during the audit, after paying for the auditor's time. A policy that claims "24/7 SOC monitoring" when you don't have a SOC creates an exception the auditor must document. These findings extend audit timelines and increase costs. AI-written policies from your codebase avoid this by only claiming what exists. ## Where Screenata Fits Screenata generates policies by reading your GitHub repos and cloud accounts. Each policy statement references your actual tools and configurations, creating a natural match between documentation and implementation. --- ### Why do auditors prefer screenshots over API logs? *Keywords: screenshot vs API evidence, visual evidence SOC 2, audit evidence preference* *Source: https://screenata.com/resources/answers/why-do-auditors-prefer-screenshots-over-api-logs* ## Why Screenshots Win SOC 2 auditors are CPAs, financial auditors who specialize in controls. Most are not software engineers. When they review evidence, they need to quickly determine: "Does this prove the control is working?" A screenshot of MFA settings showing "Enforced: Yes" answers that question instantly. A JSON API response with `"mfaPolicy": {"enforcementMode": "REQUIRED", "allowedMethods": ["TOTP", "FIDO2"]}` requires interpretation. ## Screenshots vs. API Evidence | Factor | Screenshots | API Logs/Exports | |--------|------------|-----------------| | Readability | Instant, visual context | Requires parsing | | Auditability | Easy for non-technical auditors | Needs engineering interpretation | | Context | Shows the full interface | Shows raw data without UI context | | Manipulation risk | Harder to fake convincingly | Easier to edit text/JSON | | Timestamp proof | Visible clock/date in browser | Metadata can be modified | | Completeness | Shows what you see | May miss visual indicators | ## When API Evidence Works API logs aren't rejected, they're just not preferred as primary evidence. They work well as *supporting* evidence: - CloudTrail logs supporting a screenshot of enabled audit logging - GitHub API data showing PR review statistics alongside PR screenshots - User list CSVs alongside screenshots of the admin console The best evidence combines both: a screenshot for the auditor to review, plus API data for completeness. ## The IPE Factor API exports are classified as Information Produced by Entity (IPE). Auditors must validate IPE for completeness and accuracy before relying on it. Screenshots from admin consoles carry more weight because the auditor can see the system's own interface, not a report you generated. ## Where Screenata Helps Screenata captures application-level evidence as screenshots with embedded metadata, timestamps, user context, and control identifiers. This gives auditors the visual proof they prefer while maintaining the traceability and structure they need. --- ### Why do auditors reject CSV exports as evidence? *Keywords: SOC 2 evidence format, CSV vs screenshots, audit evidence rejection* *Source: https://screenata.com/resources/answers/why-do-auditors-reject-csv-exports-as-evidence* ## Why CSVs Aren't Enough A CSV file is just text. Anyone with a spreadsheet editor can add rows, remove rows, or change values. Auditors know this, which is why they classify CSV exports as IPE (Information Produced by Entity), evidence that requires extra validation before it can be relied upon. ## The Problem with CSV-Only Evidence | Issue | Why It Matters | |-------|---------------| | Easy to edit | Auditor can't confirm the data wasn't modified | | No visual context | No way to see the source system's interface | | No timestamp proof | File metadata can be changed | | Missing completeness | No way to verify all records are included | | Requires validation | Auditor must independently check a sample against the source | ## What Auditors Actually Do with CSVs When you provide a CSV (e.g., a user access list), the auditor will: 1. Ask you to show them the source system 2. Spot-check 3-5 entries from the CSV against the live system 3. Check if the CSV includes all users (compare total count) 4. Look for records that should be there but aren't This validation step adds time to your audit. Screenshots reduce it. ## The Better Approach Provide screenshots of the source system *alongside* CSV exports. For example: - **User access review:** Screenshot of the Google Workspace admin panel showing the full user list + a CSV export of users with roles - **Security settings:** Screenshot of the settings page showing the configuration + a JSON export as supporting documentation - **Deployment history:** Screenshot of the Vercel dashboard showing recent deployments + API export of deployment records The screenshot gives the auditor visual confidence. The export gives them detailed data to analyze. ## When CSVs Work CSVs are fine as *supporting* evidence when accompanied by screenshots or system demonstrations. They're useful for large datasets (200+ users, hundreds of deployments) where a screenshot can't capture every entry. The key: never submit a CSV as the sole evidence for a control. --- ### Why do auditors reject generic SOC 2 policy templates? *Keywords: SOC 2 template problems, generic policies fail, policy specificity* *Source: https://screenata.com/resources/answers/why-do-auditors-reject-generic-soc-2-policy-templates* ## Why Templates Fail SOC 2 policy templates are designed to work for any company. That's their selling point, and their weakness. To be universal, they use generic language that doesn't describe any specific company's systems. Auditors aren't checking whether you have *a* policy. They're checking whether your policy accurately describes controls they can test. Generic language makes that impossible. ## Examples of Template Language That Fails | Template Language | Auditor's Problem | What They Want Instead | |-------------------|-------------------|----------------------| | "Industry-standard encryption is used" | Which standard? Where? | "AES-256 encryption on Supabase PostgreSQL, TLS 1.3 for transit" | | "Access is controlled through appropriate mechanisms" | What mechanisms? | "Google Workspace SSO with hardware MFA for all employees" | | "Changes follow an established process" | What process? | "GitHub PRs with required review and branch protection on main" | | "Regular security assessments are conducted" | How regular? What type? | "Annual risk assessment by the CTO, quarterly access reviews" | ## The Three Reasons Templates Get Rejected ### 1. They Include Controls You Don't Have Templates mention SIEM tools, DLP systems, dedicated security teams, and formal change advisory boards. If you're a 15-person startup, you probably have none of these. Including them creates promises you can't fulfill. ### 2. They're Too Vague to Test An auditor can't verify "appropriate access controls." They can verify "GitHub repository access is limited to engineering team members with individual accounts and branch protection requiring one approval." ### 3. They Don't Match Your Stack Templates don't know you use Vercel, Supabase, and Clerk. They use placeholder language that requires extensive customization, which most startups skip. ## What to Do Instead Either customize templates thoroughly (replacing every generic phrase with your specific tools and processes) or use a tool like Screenata that generates policies from your actual codebase and configuration. The second approach is faster and produces more accurate results. --- ### Why do Drata and Vanta assume you already have compliance expertise? *Keywords: Drata assumptions, Vanta expertise gap, compliance platform problem* *Source: https://screenata.com/resources/answers/why-do-drata-and-vanta-assume-you-already-have-compliance-expertise* ## The Expertise Assumption Drata and Vanta are enterprise compliance platforms. Their original customers were companies with security teams, people who already understood SOC 2 and needed a workspace to organize their compliance program. The platforms automate the *mechanical* parts (monitoring cloud configs, storing documents) but leave the *intellectual* parts to the user. When these platforms started selling to startups, the expertise assumption stayed. The UI looks simple, but using it effectively requires knowing: - Which Trust Services Criteria to include in scope - How to map your infrastructure to SOC 2 controls - What policies to write and how to customize them for your stack - What evidence proves each control operates effectively - How to prepare for auditor walkthroughs ## Where the Gap Shows Up | Platform Feature | What a Compliance Expert Sees | What a Founder Sees | |-----------------|------------------------------|-------------------| | Policy templates | Starting point to customize | Confusing documents with gaps | | Control checklist | Clear action items | Unfamiliar jargon | | Evidence requests | Knows exactly what to capture | "What does this mean?" | | Monitoring alerts | Quick fixes | Unclear remediation steps | | Audit preparation | Standard workflow | Overwhelming unknowns | ## Why This Is a Problem for Startups ## The Alternative Approach Screenata was designed for teams without compliance expertise. Instead of giving you a dashboard and expecting you to figure it out, it reads your codebase and cloud setup, writes policies, collects evidence, and guides you through the process, acting as the compliance expert that Drata and Vanta assume you already have. --- ### Why do enterprise buyers require SOC 2 before signing? *Keywords: enterprise SOC 2 requirement, SOC 2 for sales, SOC 2 deal blocker* *Source: https://screenata.com/resources/answers/why-do-enterprise-buyers-require-soc-2-before-signing* ## Why Do Enterprise Buyers Require SOC 2? Enterprise companies have their own compliance obligations, SOC 2, ISO 27001, or industry-specific regulations. Those frameworks require them to assess the security of every vendor that touches their data. A SOC 2 report is the standard way to satisfy that requirement without conducting a custom audit of your company. ## What Enterprise Security Teams Are Looking For | What They Need | How SOC 2 Helps | |---------------|----------------| | Independent verification of security controls | SOC 2 report is issued by a licensed CPA firm | | Evidence of access management | Report covers CC6.1–CC6.3 (logical access) | | Change management practices | Report covers CC8.1 (change management) | | Incident response capability | Report covers CC7.3–CC7.4 (response and remediation) | | Ongoing monitoring | Type II shows controls operated over time | | Risk management | Report covers CC3 (risk assessment) | ## The Buyer's Perspective Enterprise security teams review dozens of vendors per quarter. Without SOC 2, they must: 1. Send a 200+ question security questionnaire 2. Schedule calls with your engineering team 3. Review your infrastructure documentation manually 4. Write an internal risk assessment 5. Get approval from their CISO or risk committee This process takes 4–8 weeks per vendor. A SOC 2 report compresses it to a few days, the security team reads the report, checks for exceptions, and moves to contract. ## What Happens Without SOC 2 Without a SOC 2 report, one of three things happens: - **The deal stalls**, Security review takes weeks, momentum dies - **The deal requires extra negotiation**, Buyer adds security requirements to the contract - **The deal is rejected**, Competitor with SOC 2 wins ## The ROI Argument --- ### Why do GRC platforms still require a consultant? *Keywords: Drata needs consultant, Vanta needs vCISO, GRC platform limitations* *Source: https://screenata.com/resources/answers/why-do-grc-platforms-still-require-a-consultant* ## Why Can't a GRC Platform Handle SOC 2 Alone? GRC platforms are monitoring and storage tools. They watch your infrastructure, flag misconfigurations, and give you a place to organize policies and evidence. What they don't do is tell you *what* to do, they assume you already know. Here's the gap: | What the GRC Platform Does | What You Still Need a Human (or AI) For | |----------------------------|-----------------------------------------| | Monitors AWS/GCP/Azure configs | Decides which controls apply to your business | | Stores policy documents | Writes policies that match your actual systems | | Tracks employee training | Determines what training is required | | Flags missing evidence | Tells you how to generate that evidence | | Provides a compliance dashboard | Interprets what auditors are looking for | ## The Expertise Problem SOC 2 isn't just a checklist you complete. It requires judgment: Which Trust Services Criteria should you include? How do you scope the audit to avoid unnecessary work? What does "operating effectively" mean for your specific setup? What evidence proves a control works? GRC platforms don't answer these questions. They present checkboxes and expect you to know what goes in each one. For a first-time founder, that's like handing someone a blank tax return and expecting them to fill it out without an accountant. ## What Consultants Actually Do ## The Alternative AI compliance tools like Screenata close this expertise gap without a human consultant. By reading your codebase and cloud configuration directly, the AI understands your systems and provides the compliance guidance that GRC platforms lack, at a fraction of the cost. --- ### Why do most startups overpay for SOC 2? *Keywords: SOC 2 overspending, SOC 2 cost optimization, SOC 2 waste* *Source: https://screenata.com/resources/answers/why-do-most-startups-overpay-for-soc-2* ## Why Do Startups Overpay? ## The Three Overspending Traps ### 1. Buying an Enterprise GRC Platform ### 2. Hiring a Consultant to Configure the Platform ### 3. Using an Expensive Auditor ## The Math ## How to Stop Overpaying --- ### Why do SOC 2 policies fail audits when written by ChatGPT? *Keywords: AI generated SOC 2 policies, ChatGPT SOC 2, SOC 2 policy mistakes* *Source: https://screenata.com/resources/answers/why-do-soc-2-policies-fail-audits-when-written-by-chatgpt* ## Why ChatGPT Policies Don't Work ChatGPT is trained on general knowledge, not on your company's systems. When you ask it to write a SOC 2 access control policy, it produces a plausible-sounding document based on patterns from its training data. The problem: it describes a fictional company's controls, not yours. ## What Goes Wrong | ChatGPT Writes | Reality at Your Startup | Audit Impact | |----------------|------------------------|-------------| | "Security Information and Event Management (SIEM) platform monitors all systems" | You don't have a SIEM | Auditor asks to see the SIEM, you can't show one | | "Quarterly penetration testing by a third-party firm" | You've never done a pentest | Missing evidence for a claimed control | | "Data Loss Prevention (DLP) tools monitor data exfiltration" | No DLP tooling in place | Policy-to-reality gap creates a finding | | "Segregation of duties ensures no single person controls the change process" | Your CTO reviews and deploys code | Auditor flags inconsistency | ## The Core Problem Every statement in your policy is a promise to the auditor. If you promise 24/7 monitoring but only have basic CloudWatch alarms, the auditor will note the gap. ChatGPT doesn't know what you actually have, so it makes promises you can't keep. ## How It's Different from AI Compliance Tools ChatGPT writes policies from *training data*. AI compliance tools like Screenata write policies from *your codebase*. There's a critical difference: - **ChatGPT:** "Access is managed through a centralized identity provider with SSO and MFA." - **Screenata:** "Employee access is managed through Google Workspace with SAML SSO. MFA is enforced via hardware security keys. Application authentication uses NextAuth with email/password and TOTP." The second version is testable. The auditor can verify each claim against your actual systems. ## The Fix If you've already used ChatGPT for policy drafts, review every statement against your actual systems. Remove anything that describes tools or processes you don't have. Add specific references to the tools you actually use. Or use a codebase-aware tool that generates accurate policies from the start. --- ### Why do SOC 2 policies need to match your actual systems? *Keywords: SOC 2 policy accuracy, policy matches implementation, policy-control alignment* *Source: https://screenata.com/resources/answers/why-do-soc-2-policies-need-to-match-your-actual-systems* ## How Auditors Test Controls SOC 2 auditing follows a straightforward process: 1. Read your policies to understand what controls you claim to have 2. Examine your systems to see what controls actually exist 3. Compare the two If they match, the control passes. If they don't, it's a finding, also called an exception or deviation. ## What Mismatches Look Like | Policy Claims | Reality | Audit Result | |---------------|---------|-------------| | "Two reviewer approvals required for all code changes" | GitHub branch protection requires 1 reviewer | Exception, policy is stricter than implementation | | "MFA enforced for all employees" | 3 employees still use password-only | Exception, control not operating effectively | | "Quarterly access reviews documented" | Last review was 7 months ago | Exception, control not operating consistently | | "Automated vulnerability scanning runs weekly" | Dependabot checks on push but no weekly schedule | Exception, policy doesn't match actual cadence | ## Why This Happens to Startups Startups move fast. The authentication provider changes, the deployment pipeline gets updated, team size doubles, but the policies written three months ago still describe the old setup. Or worse, the policies were copied from templates and never matched reality in the first place. ## Two Ways to Fix It **Fix the systems:** If your policy says "two approvals required," update your GitHub branch protection to require two approvals. **Fix the policy:** If one approval is what your team actually does (and it's acceptable to the auditor), update the policy to say "one approval required." Either direction works. What doesn't work is a gap between the two. ## Prevention The best approach is writing policies from your systems rather than writing policies and trying to configure your systems to match. Tools like Screenata read your codebase and generate policies that describe your actual setup, eliminating the gap before the auditor arrives. --- ### Why does SOC 2 take longer than founders expect? *Keywords: SOC 2 surprise, SOC 2 delays, underestimating SOC 2* *Source: https://screenata.com/resources/answers/why-does-soc-2-take-longer-than-founders-expect* ## Why Does SOC 2 Surprise Founders? Most founders assume SOC 2 is a technical project, install some security tools, run some scans, get a certificate. In reality, SOC 2 is an operational documentation exercise. The controls often already exist; the work is writing them down, collecting evidence, and organizing everything for an auditor. ## The Four Surprises ### 1. Policy Writing Takes Weeks, Not Hours You need 4–7 formal policies that accurately describe your infrastructure and processes. Writing a single information security policy that an auditor will accept takes 4–8 hours if you know what you are doing. Most first-timers spend 2–3 weeks on policies alone. ### 2. Evidence Collection Is a Full-Time Job | Evidence Type | Quantity | Time Per Item | |--------------|----------|---------------| | Screenshots of configurations | 30–80 | 5–15 minutes each | | Policy documents | 4–7 | 4–8 hours each | | Access review records | 1–4 per quarter | 2–4 hours each | | Change management samples | 25–40 PRs | 5 minutes each to verify | | Vendor assessments | 5–15 vendors | 1–2 hours each | ### 3. Auditors Book Out 4–8 Weeks Most startup-friendly audit firms are booked weeks in advance. If you need a report by a specific date, work backward from the auditor's availability. ### 4. The Gap Between "We Do This" and "We Can Prove It" Startups usually follow decent security practices but have no documentation. The auditor does not care what you do, they care what you can prove. Closing this gap is where most time goes. ## How to Avoid the Delays - Use AI tools to generate policies from your actual infrastructure (saves weeks) - Start evidence collection on day one, not after controls are implemented - Book your auditor before you start preparation - Keep scope small, Security-only, production systems only Screenata eliminates the biggest delays by generating policies from your codebase and automating evidence collection, compressing months of manual work into weeks. --- ### Why does your SOC 2 auditor keep asking for more evidence? *Keywords: SOC 2 additional evidence, auditor evidence requests, audit rework* *Source: https://screenata.com/resources/answers/why-does-your-soc-2-auditor-keep-asking-for-more-evidence* ## Common Reasons for Additional Evidence Requests | Reason | Example | How to Prevent | |--------|---------|---------------| | Missing timestamp | Screenshot has no date visible | Include system clock or page timestamp | | Wrong environment | Captured staging instead of production | Always capture from production | | Unclear what's shown | Cropped too tightly, context lost | Include URL bar and page header | | Insufficient sample size | Provided 5 PRs, auditor needs 25 | Ask auditor for expected sample sizes upfront | | Missing period coverage | Evidence only shows one month of a 6-month period | Collect evidence throughout the observation period | | Policy-evidence gap | Policy claims control the evidence doesn't demonstrate | Align policies with what you can actually prove | ## The Cycle That Frustrates Startups 1. You submit evidence 2. Auditor reviews it 3-5 business days later 3. Auditor requests additional or clearer evidence 4. You spend 2-3 hours re-collecting 5. Submit again, wait another 3-5 days 6. Repeat This cycle can extend an audit by weeks. The fix is frontloading quality: make sure every piece of evidence is clear, timestamped, and from the right environment before the first submission. ## How to Minimize Follow-Up Requests **Before the audit:** - Ask your auditor for their evidence request list (most have a standard template) - Ask what sample sizes they expect for population testing - Confirm which environment they want to see (production, always) **During evidence collection:** - Include the browser URL bar in every screenshot - Show a visible date/time in every capture - Name files descriptively: "aws-iam-mfa-enforcement-2026-03.png" - Organize evidence by control (CC6.1, CC7.2, CC8.1) **If the auditor asks for more:** - Clarify exactly what they need before recollecting, ask for a specific example of acceptable evidence - Address all requests in one batch rather than one at a time --- ### Why is AI compliance getting cheaper faster than traditional compliance? *Keywords: AI compliance cost trend, compliance cost reduction, SOC 2 price drop* *Source: https://screenata.com/resources/answers/why-is-ai-compliance-getting-cheaper-faster-than-traditional-compliance* ## The Cost Trajectories Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). Traditional compliance costs rise slowly. AI compliance costs drop faster. ## Why Traditional Costs Rise **Platform costs increase.** GRC platforms raise prices annually as they add enterprise features most startups don't need. **Manual work doesn't scale.** A consultant takes 50+ hours per engagement regardless of whether it's their 1st or 100th client. There are no economies of scale in manual policy writing. ## Why AI Costs Drop **Models improve.** Each generation of AI models is better at code analysis, policy generation, and evidence mapping. Better output means less human review time. **Zero marginal cost for analysis.** Once built, an AI compliance tool can analyze a new codebase for near-zero incremental cost. The 1,000th customer costs the same as the 10th to serve. **Evidence collection automates further.** As AI tools build more integrations and improve screenshot automation, the percentage of evidence collected automatically increases, reducing the remaining manual work each year. **Competition drives pricing down.** As more AI compliance tools enter the market, competition reduces prices while improving features. ## The Cost Floor ## What This Means for Startups --- ### Why is everyone updating their privacy policy in 2026? *Keywords: privacy policy update 2026, new state privacy laws 2026, US state privacy laws, privacy policy requirements* *Source: https://screenata.com/resources/answers/why-is-everyone-updating-their-privacy-policy-in-2026* ## Why is everyone updating their privacy policy in 2026? Because the law under those policies changed in batches. A wave of new US state consumer privacy laws took effect through 2025 and into January 2026: Tennessee and Minnesota in mid-2025, Maryland in October 2025, and Indiana, Kentucky, and Rhode Island on January 1, 2026. Each new law adds required disclosures and consumer rights, so companies serving US consumers have been revising policies on the same schedule the laws arrive. By early 2026, roughly 20 states have such laws in force. ## The drivers, in one place | Driver | What changed | What it forces into the policy | |---|---|---| | New state privacy laws | Tennessee, Minnesota (mid-2025), Maryland (Oct 2025), Indiana, Kentucky, Rhode Island (Jan 2026) | State-specific rights sections, opt-out links for targeted ads and data sales, contact and appeal mechanisms | | Stricter existing states | Maryland's law imposes unusually tight data minimization and largely bans selling sensitive data | Narrower stated purposes for collection; some practices must stop, not just be disclosed | | EU AI Act phase-in | Transparency obligations for AI systems phasing in through 2025 and 2026 | Disclosure when users interact with AI, and how personal data feeds AI features | | Enforcement pressure | FTC and state AG actions on dark patterns and vague "sale" disclosures | Plain-language opt-outs, honest descriptions of data sharing with ad tech | | Universal opt-out signals | Several states now require honoring browser signals such as Global Privacy Control | A statement of whether and how opt-out preference signals are honored | ## Why the updates cluster in January Most state privacy laws take effect on January 1. Legal teams typically batch the changes: audit data practices in the fall, publish one revised policy before the effective dates, and notify users once. That is why inboxes fill with "we've updated our privacy policy" emails each December and January, and why 2026 looks like "everyone at once" when it is really three new states plus amendments landing on the same date. ## What "update" actually means A meaningful update is rarely just new text. The state laws grant rights (access, deletion, correction, portability, opt-out of targeted advertising and data sales) that the company must be able to honor operationally. The policy update is the visible end of a chain: data inventory, vendor review, opt-out plumbing, then the rewritten disclosure. A policy that promises rights the company cannot fulfill is worse than an old one, because misdescribing your practices is the core of most FTC and state enforcement. Two clarifications, since the question hides an ambiguity. First, "privacy policy" here means the public-facing notice to consumers, which is different from internal privacy and security policies that frameworks like SOC 2 or ISO 27001 examine; the 2026 wave is about the public notice. Second, most of these state laws have applicability thresholds, commonly around 100,000 state residents' data processed per year, or 25,000 if you sell data. Small B2B companies that process little consumer data are often below every threshold, and many of them update anyway because enterprise customers and privacy-conscious users expect current state coverage. ## Do you need to act? If you serve US consumers in any volume, yes: check whether Indiana, Kentucky, Rhode Island, or Maryland cover you, and whether your policy discloses opt-out rights and honors universal opt-out signals where required. If you are a B2B vendor below the thresholds, the direct legal risk is low, but expect the question to arrive through customer security and privacy reviews instead. Either way, the underlying rule is stable even as statutes multiply: describe what you actually do with data, accurately, and revisit the description every time the practices or the laws change. --- ### Why is SOC 2 becoming table stakes for B2B SaaS? *Keywords: SOC 2 table stakes, B2B SaaS compliance, SaaS security requirements* *Source: https://screenata.com/resources/answers/why-is-soc-2-becoming-table-stakes-for-b2b-saas* ## Why Is SOC 2 Table Stakes Now? Five years ago, only large enterprises asked for SOC 2 reports. Today, mid-market companies with 100+ employees routinely require them during vendor review. The shift happened because of increasing data breaches, stricter regulations, and the realization that vendor risk is a primary attack vector. ## What Changed | Driver | Impact on SOC 2 Demand | |--------|----------------------| | High-profile data breaches | Boards now require vendor security assessments | | Cyber insurance requirements | Insurers ask about vendor compliance programs | | Regulatory pressure (GDPR, CCPA) | Companies must demonstrate they vet vendors | | Remote work expansion | More SaaS tools = more vendors to evaluate | | Supply chain attacks | SolarWinds and similar incidents raised awareness | | Buyer sophistication | Even mid-market companies now have security teams | ## The Numbers - 90%+ of enterprise RFPs include SOC 2 as a requirement - Mid-market companies (100–1,000 employees) increasingly require it - The average enterprise evaluates 50+ vendors per year - SOC 2 is the fastest way to pass vendor review at scale ## What This Means for Startups If you sell B2B SaaS to companies above 100 employees, SOC 2 is no longer a competitive advantage, it is a minimum qualification. Not having it puts you at a disadvantage against competitors who do. The good news: the cost and timeline of SOC 2 have dropped significantly. AI-based compliance tools make it accessible to bootstrapped startups, not just VC-funded companies with dedicated security teams. ## The Practical Takeaway --- ### Why is SOC 2 evidence collection the biggest time sink for startups? *Keywords: SOC 2 time cost, manual evidence cost, engineering time SOC 2* *Source: https://screenata.com/resources/answers/why-is-soc-2-evidence-collection-the-biggest-time-sink-for-startups* ## Where the Time Goes Evidence collection consumes more founder and engineering time than any other part of SOC 2. Here's why: | Task | Time (Manual) | Why It Takes So Long | |------|--------------|---------------------| | Taking screenshots across all systems | 15-25 hours | Navigate to each settings page, capture, verify timestamp | | Organizing evidence by control | 10-15 hours | Map each screenshot to TSC criteria | | Population sampling | 10-20 hours | Pull 25 PRs, 15 access events, 10 incidents | | Re-capturing rejected evidence | 5-15 hours | Missing timestamps, wrong environment, unclear context | | Coordinating with auditor | 5-10 hours | Back-and-forth on what's acceptable | | **Total** | **45-85 hours** | | ## Why It's Worse Than Policy Writing Policies are a one-time effort, you write them once and update annually. Evidence collection is *ongoing*. For a Type II audit, you're collecting evidence over 3-12 months. If you miss a quarterly access review in month 4, you can't go back and create it. ## The Application-Level Gap GRC platforms automate infrastructure monitoring (AWS configs, MFA status, endpoint compliance). But they can't capture: - Your application's admin panel showing role-based access - Feature flag approval workflows - In-app data handling controls - Custom permission enforcement This application-level evidence is still captured manually, logging into your app, navigating to settings pages, taking screenshots, and organizing them. For a product with multiple admin screens and control points, this alone takes 10-20 hours. ## The Audit Rework Problem The worst time sink isn't the first pass, it's the rework. Auditors frequently request additional evidence or reject screenshots that lack timestamps, show the wrong environment, or don't clearly demonstrate the control. Each round of rework costs 3-5 hours. ## How to Reduce the Time - **Automate infrastructure evidence** with a GRC platform or API integrations - **Use Screenata** for application-level evidence (automated screenshots with timestamps) - **Create an evidence calendar**, schedule quarterly reviews, monthly log checks, and other recurring evidence tasks - **Start evidence collection on day one** of your observation period, not the week before the audit --- ### Why is SOC 2 more expensive than founders expect? *Keywords: SOC 2 hidden costs, SOC 2 total cost, unexpected SOC 2 expenses* *Source: https://screenata.com/resources/answers/why-is-soc-2-more-expensive-than-founders-expect* ## Why Does SOC 2 Cost More Than Expected? ## The Hidden Cost Stack Model your own numbers with the [SOC 2 cost calculator](/tools/soc-2-cost-calculator). ## Why Each Hidden Cost Exists **Consultants**, GRC platforms provide dashboards, not expertise. Someone still needs to write policies, map controls, and prepare for the audit. That is usually a vCISO or compliance consultant. **Engineering time**, Taking screenshots, exporting configurations, answering auditor questions, and fixing gaps found during testing. This is rarely budgeted for. **Renewal costs**, SOC 2 is not a one-time event. Type II requires annual audits. Platform and auditor fees recur every year. ## How to Avoid the Surprise --- ### How much does Vanta cost, and is it worth it at renewal? *Keywords: Vanta pricing, Vanta cost, how much does Vanta cost, Vanta renewal, is Vanta worth it, Vanta alternative* *Source: https://screenata.com/resources/answers/why-is-vanta-15k-per-year* ## How much does Vanta cost in 2026? ## What Vanta costs, line by line These are prices buyers paid. Vanta has no public rate card, and Vendr reports that volume, multi-year terms and competing quotes commonly take 15–30% off an initial quote. ## What happens to Vanta's price at renewal? Vendr's data on Vanta contracts shows how the price moves at renewal: - Annual escalation clauses of 5–10% a year are common. Vendr notes that over a three-year contract, a 10% annual increase compounds to 33%. - Renewal quotes often come in 10–20% higher unless you renegotiate. Buyers who push back instead of accepting the auto-renewal price typically land 10–20% below Vanta's first renewal quote. - If your headcount grows past the contracted tier, Vanta may charge overage fees or move you up a tier mid-contract. Find the renewal date and the notice deadline in your order form before the renewal quote arrives. Accepting that quote as it arrives is the most expensive option in Vendr's data. ## Is Vanta worth it at renewal? It depends on who does the work in your program. Vanta is worth renewing when someone works in it every week and you use the modules you pay for. It is harder to justify when your team still gathers most of the evidence by hand. Screenshots are a large share of that hand work. Vanta reported in August 2026 that 36% of the 650,000 images uploaded to it over six months were screenshots, evidence that sits outside any integration. If you decide to move, [switching compliance platforms during a SOC 2 observation period](/resources/answers/can-i-switch-compliance-platforms-during-a-soc-2-observation-period) covers timing, what to export before your contract ends, and keeping your auditor. ## What does SOC 2 cost with Vanta, all in? The licence is usually the smaller part of the bill. You also pay the auditor, and someone has to run the program: your own team, or a vCISO on a monthly retainer. A rep can discount the licence, but the hours it takes to run the program stay the same. ## When is Vanta the right choice? Vanta fits a company with a compliance owner who works in the platform daily, frameworks beyond SOC 2, and customers or auditors who already know the brand. It has the largest integration catalog in the category and supports more than 35 frameworks, and at 100 or more employees the licence is a small line next to headcount. A team under 50 on its first or second SOC 2 uses a small part of that catalog, and its people still gather the evidence that sits outside the integrations. For the full list of Vanta alternatives, what each costs and who audits, see [Vanta alternatives compared](/compare/vanta). --- ### Why will auditors accept AI-generated SOC 2 evidence? *Keywords: auditor AI acceptance, AI evidence credibility, automated evidence trust* *Source: https://screenata.com/resources/answers/why-will-auditors-accept-ai-generated-soc-2-evidence* ## What Auditors Actually Evaluate Auditors assess evidence on three criteria: 1. **Relevance:** Does this evidence relate to the control being tested? 2. **Reliability:** Can I trust this evidence is accurate and unaltered? 3. **Sufficiency:** Is there enough evidence to support a conclusion? None of these criteria specify *who* or *what* collected the evidence. A screenshot is a screenshot whether a human took it or an AI tool captured it. ## Why AI Evidence Can Be More Reliable | Factor | Human-Collected | AI-Collected | |--------|----------------|--------------| | Timestamp consistency | Sometimes forgets to show clock | Always includes timestamp | | Context | May crop too tightly | Captures full page context | | Naming convention | Inconsistent (screenshot1.png) | Consistent (CC6.1-mfa-google-2026-03.png) | | Coverage | May miss systems | Systematically covers all connected systems | | Frequency | Point-in-time snapshots | Continuous or scheduled captures | | Repeatability | Different each time | Same process, consistent output | ## What Auditors Will Verify Regardless of collection method, auditors will: 1. **Spot-check against the live system.** They may ask to see the same admin panel the screenshot shows. 2. **Verify timestamps.** The evidence must be from the audit period. 3. **Check completeness.** Does the evidence cover all in-scope systems? 4. **Validate IPE.** If the AI generates reports (not screenshots), auditors treat these as Information Produced by Entity and validate accuracy. ## The Growing Acceptance Auditors already accept evidence from automated tools. GRC platforms like Drata and Vanta have used API-based evidence collection for years. AI-generated evidence is the next evolution, more comprehensive, more consistent, and covering application-level controls that API-only tools miss. ## Where Screenata Fits Screenata generates evidence with full traceability, timestamps, system identifiers, control mappings, and the ability for auditors to verify captures against live systems. This audit trail gives auditors confidence in the evidence regardless of the collection method. --- ### Do you still need a vCISO for SOC 2? *Keywords: SOC 2 without vCISO, vCISO SOC 2, AI compliance* *Source: https://screenata.com/resources/answers/why-you-probably-dont-need-a-vciso-for-soc-2-anymore* ## Do You Still Need a vCISO? It depends on what you're paying them for. Most of a vCISO's SOC 2 hours go to repeatable operational work: translating framework requirements into policies, mapping controls, and guiding evidence collection. AI compliance tools now do that layer automatically, by reading your actual infrastructure instead of interviewing your team. What a vCISO uniquely provides is judgment: owning your security program, making risk-acceptance calls, and handling the unusual scenarios where experience matters. That part isn't going away. ## The Operational Layer vs. the Advisory Layer | Task | Operational (AI handles) | Advisory (a vCISO adds value) | |------|--------------------------|-------------------------------| | Write policies | Reads codebase and cloud config, generates policies | Decides which commitments the business can actually stand behind | | Map controls | Automatic mapping from infrastructure analysis | Interprets ambiguous scope and edge cases | | Identify gaps | Scans systems and flags gaps instantly | Prioritizes remediation against business risk | | Guide evidence | Generates specific evidence requirements per control | Owns the relationship with the auditor | | Audit prep | Produces organized evidence packages | Represents you in board and customer conversations | ## When You Still Want a vCISO - You are pursuing SOC 2 + ISO 27001 + HIPAA simultaneously - Your infrastructure is complex (hybrid cloud, legacy systems, multiple data centers) - You need someone to own your security program long-term, not just audit prep - Your auditor raises concerns that require expert interpretation ## The Cost Difference ## The Verdict For a simple first audit, an AI tool covers the operational layer so you don't have to buy those hours. If your needs grow beyond a single framework, or you want a security leader who owns the program, a vCISO is worth it, and the two work well together. That's exactly how many vCISO firms now operate: Screenata runs the operational work across their clients, reading each client's infrastructure, drafting policies, and collecting evidence, so their team spends its hours on judgment and takes on more engagements at the same headcount. See [Screenata for vCISO firms](/for-vcisos). --- ## Blog Posts Full articles available at the linked .md URLs. ### The Real Cost of SOC 2: Why the Cheapest Platform Isn't the Cheapest Program *Published: 2026-09-14 | Source: https://screenata.com/resources/blog/the-real-cost-of-soc-2-why-the-cheapest-platform-isnt-the-cheapest-program.md* Dropping the platform saves the licence and costs more in hours. 2026 prices for 11 compliance platforms, sourced. ### Do Auditors Accept AI-Captured Screenshots for SOC 2? *Published: 2026-08-18 | Source: https://screenata.com/resources/blog/do-auditors-accept-ai-captured-screenshots-for-soc-2.md* Yes, when the artifact carries what an auditor needs. Auditors evaluate the evidence rather than the hand that captured it, so an agent-captured screenshot is accepted on the same terms as one a person took, and it fails on the same terms. Vanta reported that 36% of the 650,000 images uploaded to its platform over six months were screenshots, which is the best public measure of how much visual proof survives full API automation. Automating the capture removes real hours and leaves two things unsolved: a captured image still has to show that a control operated across the whole period and that the sample came from a complete population, and a cloud browser cannot reach native desktop applications, sessions behind Conditional Access, or anything on premises. ### The 10 Best SOC 2 Compliance Platforms in 2026 *Published: 2026-07-25 | Source: https://screenata.com/resources/blog/best-soc-2-compliance-platforms-in-2026.md* A practical, vendor-by-vendor guide to the best SOC 2 compliance platforms in 2026, Screenata, Vanta, Drata, Secureframe, Scrut, Thoropass, Oneleet, Delve, Comp AI, and ComplyJet, with what each actually does, what each costs, and who each fits. The category is splitting into dashboards you drive and agents that do the work. ### Best AI Compliance Platform for Startups in 2026 *Published: 2026-07-09 | Source: https://screenata.com/resources/blog/best-ai-compliance-platform-for-startups-in-2026.md* The best AI compliance platform for startups in 2026 is the one that does the work, not the one with the nicest dashboard. This guide ranks seven AI-powered SOC 2 and compliance platforms for early-stage teams, what each actually automates, what it costs, and who it fits, including Screenata's agent Vera, who writes policies from your codebase, captures the evidence APIs can't reach, and chases the attestations only a person can answer. ### How to Use Slack for SOC 2 Audit Prep *Published: 2026-07-09 | Source: https://screenata.com/resources/blog/how-to-use-slack-for-soc-2-audit-prep.md* Most SOC 2 prep dies in a dashboard nobody opens. This guide shows how to run audit prep inside Slack instead: daily readiness briefings, evidence collection over DM, delegation that follows up on its own, and auditor questions answered by email. Vera, the AI compliance officer, does the work in the channel where your team already spends the day. ### How to Standardize SOC 2 Evidence Packs Across Multiple Clients *Published: 2026-05-09 | Source: https://screenata.com/resources/blog/how-to-standardize-soc-2-evidence-packs-across-multiple-clients.md* To standardize SOC 2 evidence across multiple clients, you need to normalize outputs from different tech stacks into consistent deliverable templates. This guide explains how vCISOs and MSPs use automation to format screenshots and logs so auditors receive the exact same evidence structure regardless of the client's underlying tools. ### What vCISO Tools Automate SOC 2 Evidence Collection for 10+ Clients? *Published: 2026-05-08 | Source: https://screenata.com/resources/blog/what-vciso-tools-automate-soc-2-evidence-collection-for-10-clients.md* Scaling a fractional CISO practice requires specific vCISO tools to automate SOC 2 evidence collection. This guide explains how to build a software stack that handles screenshots, standardizes artifacts, and eliminates spreadsheet tracking across 10+ clients. ### How to Automate SOC 2 Evidence Collection and Protect MSP Margins *Published: 2026-05-07 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-collection-and-protect-msp-margins.md* Manual SOC 2 evidence collection destroys MSP margins. By using automation to capture application-level screenshots and validate controls, consultants can offer competitive compliance as a service pricing without sacrificing profitability. ### The "Evidence First" Approach to Selling Compliance as an MSP *Published: 2026-05-06 | Source: https://screenata.com/resources/blog/the-.md* MSPs often sell compliance as a dashboard of gap assessments, leaving clients to do the actual work of collecting screenshots. The evidence-first approach flips this by selling automated evidence collection, reducing client friction and protecting MSP margins. ### How to Automate Multi-Tenant SOC 2 Evidence Collection Across Distinct Environments *Published: 2026-05-05 | Source: https://screenata.com/resources/blog/how-to-automate-multi-tenant-soc-2-evidence-collection-across-distinct-environments.md* Managing multiple SOC 2 audits requires strict separation of evidence across distinct client environments. This guide explains how MSPs and vCISOs can automate SOC 2 evidence collection, capture standardized screenshots across different tech stacks, and avoid the headache of manually logging into dozens of separate systems. ### How to Price Managed Compliance Services to Protect Your Margins *Published: 2026-05-04 | Source: https://screenata.com/resources/blog/how-to-price-managed-compliance-services-to-protect-your-margins.md* You can protect your managed compliance margins by pricing based on automated evidence collection rather than manual hours. This guide explains how to structure your vCISO rates, price SOC 2 services, and stop losing money on manual screenshots. ### The vCISO Tech Stack: Essential Tools for Automating SOC 2 Evidence Collection *Published: 2026-05-03 | Source: https://screenata.com/resources/blog/the-vciso-tech-stack-essential-tools-for-automating-soc-2-evidence-collection.md* Scaling a vCISO practice requires automating SOC 2 evidence collection across multiple clients. This guide breaks down the essential tools for managing policies, capturing screenshots, and assembling audit-ready documentation without killing your margins. ### How to Build a Trust Center That Accelerates ISO 27001 Security Reviews *Published: 2026-05-02 | Source: https://screenata.com/resources/blog/how-to-build-a-trust-center-that-accelerates-iso-27001-security-reviews.md* A well-structured trust center provides proactive transparency and reduces security questionnaire volume. This guide explains how to build a trust center, what security documentation to include, and how to automate evidence collection to keep it updated. ### How to Map ISO 27001 Evidence to SOC 2 and HIPAA Controls *Published: 2026-05-01 | Source: https://screenata.com/resources/blog/how-to-map-iso-27001-evidence-to-soc-2-and-hipaa-controls.md* Yes, you can reuse up to 80% of your compliance evidence across frameworks. This guide explains how to map ISO 27001 Annex A evidence to SOC 2 Trust Services Criteria and HIPAA safeguards, and how automation makes multi-framework audits manageable. ### How to Automate ISO 27001 Cloud Provider and Multi-Location Evidence with Screenshots *Published: 2026-04-30 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-cloud-provider-and-multi-location-evidence-with-screenshots.md* ISO 27001 auditors require consistent evidence across every physical office and cloud environment in your ISMS scope. This guide explains how to automate ISO 27001 evidence collection for Annex A cloud controls and multi-location physical security without flying assessors to every site. ### ISO 27001 for SaaS Companies: Evidence Collection Guide *Published: 2026-04-29 | Source: https://screenata.com/resources/blog/iso-27001-for-saas-companies-evidence-collection-guide.md* ISO 27001 auditors require evidence for every applicable Annex A control in your Statement of Applicability. This guide shows how SaaS companies can automate ISO 27001 evidence collection to eliminate manual screenshot taking and speed up certification. ### How to Automate ISO 27001 Management Review Evidence Collection *Published: 2026-04-28 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-management-review-evidence-collection.md* ISO 27001 auditors require proof that leadership actively runs the ISMS through management reviews and continual improvement tracking. This guide explains how to document Clause 9.3 and Clause 10 requirements and automate the collection of administrative evidence. ### How to Automate ISO 27001 Risk Treatment and Business Continuity Evidence *Published: 2026-04-27 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-risk-treatment-and-business-continuity-evidence.md* ISO 27001 certification requires proof that your Risk Treatment Plan is active and your business continuity controls actually work. This guide explains how to automate ISO 27001 evidence collection for risk remediation and disaster recovery testing. ### How to Automate ISO 27001 Annex A.8 Evidence Collection with Screenshots *Published: 2026-04-26 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-annex-a8-evidence-collection-with-screenshots.md* Yes. You can automate ISO 27001 A.8 evidence collection using tools that capture screenshots of access rights, cryptography settings, and system configurations. This guide explains what auditors actually check for technological controls and where traditional GRC platforms fall short. ### How to Automate ISO 27001 A.5 Organizational Controls Evidence with Screenshots *Published: 2026-04-25 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-a5-organizational-controls-evidence-with-screenshots.md* ISO 27001 auditors require concrete evidence for Annex A.5 organizational controls, from policy approvals to access management. This guide explains how to automate ISO 27001 evidence collection and where traditional GRC tools fall short. ### How to Automate ISO 27001 Surveillance Audit Evidence: Complete Checklist *Published: 2026-04-24 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-surveillance-audit-evidence-complete-checklist.md* ISO 27001 surveillance audits require evidence that your ISMS and Annex A controls operated continuously over the past year. This checklist explains exactly what documentation auditors expect and how to automate ISO 27001 evidence collection to avoid the pre-audit scramble. ### ISO 27001 vs SOC 2: Evidence Requirements Compared *Published: 2026-04-23 | Source: https://screenata.com/resources/blog/iso-27001-vs-soc-2-evidence-requirements-compared.md* While SOC 2 focuses on technical system controls, ISO 27001 requires evidence of a functioning Information Security Management System (ISMS). This guide explains the exact documentation and screenshots auditors expect for both frameworks and how automation bridges the gap. ### ISO 27001 Certification Timeline: How to Automate Evidence Collection with Screenshots *Published: 2026-04-22 | Source: https://screenata.com/resources/blog/iso-27001-certification-timeline-how-to-automate-evidence-collection-with-screenshots.md* The ISO 27001 certification timeline takes 6 to 9 months, but manual evidence collection often causes delays right before the Stage 2 audit. This guide explains the exact schedule for ISMS documentation and Annex A controls, and how to automate screenshots to keep your audit on track. ### How to Document Penetration Test Results for HITRUST and SOC 2 Audits *Published: 2026-04-21 | Source: https://screenata.com/resources/blog/how-to-document-penetration-test-results-for-hitrust-and-soc-2-audits.md* Both HITRUST r2 and SOC 2 require documented penetration testing and vulnerability assessment evidence. This guide explains how to document your penetration test results, track remediation efforts, and automate evidence collection so auditors accept your reports without follow-up questions. ### How to Automate HITRUST Corrective Action Plan (CAP) Documentation *Published: 2026-04-20 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-corrective-action-plan-cap-documentation.md* HITRUST Corrective Action Plans require continuous proof of remediation. This guide explains how to automate CAP evidence collection so you have exact, time-stamped documentation ready for your assessor. ### Business Associate HITRUST Requirements: Complete Evidence Checklist *Published: 2026-04-19 | Source: https://screenata.com/resources/blog/business-associate-hitrust-requirements-complete-evidence-checklist.md* Covered entities increasingly require Business Associates to achieve HITRUST r2 certification. This checklist details the exact evidence documentation, screenshots, and automation strategies needed across CSF control domains to pass your assessment. ### HITRUST vs HIPAA: How to Automate Evidence Collection for Healthcare Audits *Published: 2026-04-18 | Source: https://screenata.com/resources/blog/hitrust-vs-hipaa-how-to-automate-evidence-collection-for-healthcare-audits.md* HITRUST CSF provides the certifiable framework to prove HIPAA Security Rule compliance, but gathering evidence across 19 control domains is difficult. This guide explains how to automate HITRUST r2 evidence collection using screenshots to satisfy both frameworks. ### How to Automate HITRUST r2 Data Protection and Asset Management Evidence *Published: 2026-04-17 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-r2-data-protection-and-asset-management-evidence.md* HITRUST r2 assessments require strict evidence for data protection, privacy, and asset management across multiple CSF control domains. This guide explains how to automate evidence collection for data encryption, asset inventories, and privacy controls to pass your assessment without manual screenshotting. ### How to Automate HITRUST Security Operations Evidence Collection *Published: 2026-04-16 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-security-operations-evidence-collection.md* HITRUST r2 assessments require detailed evidence across the CSF control domains for security operations. This guide explains how to automate HITRUST evidence collection for incident response, vulnerability management, and network protection using screenshots and workflow captures. ### How to Automate HITRUST r2 Access Control Evidence with Screenshots *Published: 2026-04-15 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-r2-access-control-evidence-with-screenshots.md* HITRUST r2 assessments require technical evidence for access controls across multiple CSF control domains. This guide explains how to automate HITRUST r2 access control evidence collection with screenshots, what assessors actually look for, and where traditional GRC tools fall short. ### HITRUST Maturity Levels: How to Automate Evidence Collection for r2 Assessments *Published: 2026-04-14 | Source: https://screenata.com/resources/blog/hitrust-maturity-levels-how-to-automate-evidence-collection-for-r2-assessments.md* HITRUST r2 assessments evaluate controls across five maturity levels. While Policy and Procedure require standard documentation, the Implemented level requires manual screenshots and system configurations. This guide explains how to automate HITRUST evidence collection across all required CSF control domains. ### HITRUST e1, i1, and r2 Assessments: Which Do You Need and What Evidence Each Requires *Published: 2026-04-13 | Source: https://screenata.com/resources/blog/hitrust-e1-i1-and-r2-assessments-which-do-you-need-and-what-evidence-each-requires.md* Choosing between HITRUST e1, i1, and r2 assessments depends on your risk profile and buyer requirements. This guide explains the differences, what evidence HITRUST assessors require for each certification, and how to automate documentation collection across CSF control domains. ### How to Automate Employee Onboarding and Offboarding Evidence for Compliance *Published: 2026-04-12 | Source: https://screenata.com/resources/blog/how-to-automate-employee-onboarding-and-offboarding-evidence-for-compliance.md* Employee transitions are the most common source of SOC 2 audit exceptions. This guide explains how to automate onboarding and offboarding compliance evidence, what auditors actually check, and how to capture screenshots for systems that lack API integrations. ### Concentration Risk in Cloud Vendors: Audit Evidence Guide *Published: 2026-04-11 | Source: https://screenata.com/resources/blog/concentration-risk-in-cloud-vendors-audit-evidence-guide.md* Internal auditors increasingly flag cloud vendor concentration risk as a critical vulnerability. This guide explains what evidence auditors actually require to prove resilience against single points of failure, and how to automate the collection of vendor risk documentation. ### How to Automate ISO 42001 Evidence Collection with Screenshots *Published: 2026-04-10 | Source: https://screenata.com/resources/blog/how-to-automate-iso-42001-evidence-collection-with-screenshots.md* ISO 42001 compliance requires evidence that your AI Management System (AIMS) controls are operating effectively. This guide explains how to automate ISO 42001 evidence collection using screenshots to document data pipelines, model testing, and human oversight workflows. ### How to Audit AI Systems: Internal Audit Evidence for ISO 42001 Algorithmic Controls *Published: 2026-04-09 | Source: https://screenata.com/resources/blog/how-to-audit-ai-systems-internal-audit-evidence-for-iso-42001-algorithmic-controls.md* Auditing AI systems requires specific evidence for algorithmic controls, model training data, and human oversight. This guide explains how to automate internal audit evidence collection for ISO 42001 and SOC 2 AI controls using screenshots and workflow captures. ### Internal Audit Evidence for the 2026 Mandatory Cybersecurity Topical Requirement *Published: 2026-04-08 | Source: https://screenata.com/resources/blog/how-to-automate-internal-audit-evidence-collection-for-the-2026-mandatory-cybersecurity-topical-requirement.md* The IIA's Cybersecurity Topical Requirement makes specific technical testing mandatory for internal audits starting in February 2026. This guide explains how to automate internal audit evidence collection, replace manual screenshots, and upgrade your workpapers to meet the new standards. ### 2026 Global Internal Audit Standards: How to Automate Evidence for Gap Assessments *Published: 2026-04-07 | Source: https://screenata.com/resources/blog/2026-global-internal-audit-standards-how-to-automate-evidence-for-gap-assessments.md* The 2026 Global Internal Audit Standards require stricter documentation for control testing and quality assurance. This guide explains how to perform a gap assessment against the new IIA standards and automate evidence collection to ensure your internal audit working papers pass external review. ### From Manual Sampling to Continuous Data Testing: An Internal Audit Guide *Published: 2026-04-06 | Source: https://screenata.com/resources/blog/from-manual-sampling-to-continuous-data-testing-an-internal-audit-guide.md* Yes. Internal audit teams can replace manual sampling of 25-50 items with continuous data testing that evaluates 100% of the population. This guide explains how automated evidence collection transforms internal audit workpapers and where traditional tools fall short. ### The CAE's Business Case for Audit Automation Investment *Published: 2026-04-05 | Source: https://screenata.com/resources/blog/the-cae.md* To secure budget for audit software, CAEs must prove ROI by calculating the exact cost of manual evidence collection. This guide provides the formula to justify internal audit automation to your CFO, aligning with IIA Standard 10.3 and eliminating the hidden costs of manual screenshots. ### Internal Audit Evidence Collection Checklist for 2026 *Published: 2026-04-04 | Source: https://screenata.com/resources/blog/internal-audit-evidence-collection-checklist-for-2026.md* This 2026 internal audit evidence collection checklist covers the exact documentation and screenshots required for IT and security controls. While APIs handle infrastructure, application-level evidence requires manual collection. Learn how to automate this process to ensure your evidence meets auditor IPE standards. ### How to Automate SOC 2 CC9.2 Vendor Risk Management Evidence with AI *Published: 2026-04-03 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-cc92-vendor-risk-management-evidence-with-ai.md* Yes. A VRM AI agent can automatically review third-party security assessments, capture SOC 2 CC9.2 evidence, and document vendor approvals. This guide explains how to automate vendor risk management documentation and where traditional compliance tools fall short. ### How to Automate SOC 2 Security Questionnaires Using AIQA and Screenshot Evidence *Published: 2026-04-02 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-security-questionnaires-using-aiqa-and-screenshot-evidence.md* AI Questionnaire Assistance (AIQA) automates security questionnaire responses by reading your SOC 2 policies, extracting screenshot evidence, and drafting accurate answers. This guide explains how security questionnaire automation works, why manual reviews take so long, and where traditional tools fall short. ### AIUC-1 vs ISO 42001: Which AI Standard Applies to Your Product? *Published: 2026-04-01 | Source: https://screenata.com/resources/blog/aiuc-1-vs-iso-42001-which-ai-standard-applies-to-your-product.md* ISO 42001 evaluates your company's AI management system, while AIUC-1 evaluates the specific behavior and guardrails of your AI agent. This guide explains how to choose between these AI compliance standards and how to automate the necessary evidence documentation for audits. ### What Is AIUC-1? How to Automate AI Agent Certification Evidence *Published: 2026-03-31 | Source: https://screenata.com/resources/blog/what-is-aiuc-1-how-to-automate-ai-agent-certification-evidence.md* AIUC-1 is the emerging AI agent standard for evaluating autonomous system boundaries and decision logic. Earning an AI agent certification requires specific evidence of human-in-the-loop oversight, prompt injection protections, and action logs. Here is how to automate AIUC-1 documentation and where traditional compliance tools fail. ### How to Automate ISO 42001 and NIST AI RMF Evidence Collection *Published: 2026-03-30 | Source: https://screenata.com/resources/blog/how-to-automate-iso-42001-and-nist-ai-rmf-evidence-collection.md* Yes, you can automate evidence collection for both ISO 42001 and the NIST AI RMF. While NIST provides guidelines for AI risk management and ISO 42001 demands a certified management system, both require heavy documentation of AI models, access controls, and system changes. This article compares the evidence requirements for both frameworks and explains how to automate evidence capture for AI governance. ### Can AI Tools Capture Screenshots and Create SOC 2 Audit-Ready Reports? *Published: 2026-03-28 | Source: https://screenata.com/resources/blog/can-ai-tools-capture-screenshots-and-create-soc-2-audit-ready-reports.md* Yes. AI tools can automatically capture SOC 2 screenshots, validate them, and generate audit-ready evidence that auditors accept. This article explains how automated evidence collection works for SOC 2 and where traditional tools fall short. ### Compliance as Code: How to Automate Evidence in CI/CD Pipelines *Published: 2026-03-27 | Source: https://screenata.com/resources/blog/compliance-as-code-how-to-automate-evidence-in-cicd-pipelines.md* You can automate SOC 2 evidence in your CI/CD pipeline by triggering headless browsers to capture visual UI artifacts after deployments. While traditional DevSecOps tools log infrastructure checks, auditors still require screenshots for application-level controls. This guide explains how to bridge the gap between pipeline logs and audit-ready evidence. ### How to Automate SOC 2 Evidence Collection Across AWS, Azure, and GCP *Published: 2026-03-26 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-collection-across-aws-azure-and-gcp.md* Yes. You can automate SOC 2 evidence collection across multi-cloud environments by centralizing screenshots and API data. This guide explains how to handle cloud integrations for AWS, Azure, and GCP so you stop logging into three different consoles during an audit. ### How to Export Screenata Evidence Packs into Drata or Vanta *Published: 2026-03-25 | Source: https://screenata.com/resources/blog/how-to-export-screenata-evidence-packs-into-drata-or-vanta.md* Exporting Screenata evidence packs into Drata or Vanta helps teams already mid-audit keep their current auditor workspace while Vera does the evidence work: API scans, UI proof, attestations, signed packs, and a proof chain that stays in Screenata. ### PCI DSS Evidence Automation: What Screenshots Prove Cardholder Data Protection *Published: 2026-03-24 | Source: https://screenata.com/resources/blog/pci-dss-evidence-automation-what-screenshots-prove-cardholder-data-protection.md* Yes, you can automate PCI DSS evidence collection for application-layer controls. While GRC tools handle cloud infrastructure, QSAs still require manual screenshots to prove PAN masking, UI-based access controls, and custom workflows. This guide explains what visual evidence proves cardholder data protection and how to automate it. ### State of GRC 2026 Survey: Why Automating SOC 2 Evidence Collection Requires Screenshots *Published: 2026-03-23 | Source: https://screenata.com/resources/blog/state-of-grc-2026-survey-why-automating-soc-2-evidence-collection-requires-screenshots.md* The State of GRC 2026 survey of 795 practitioners reveals that 59% of teams lack commercial tools, relying on spreadsheets for audits. This article breaks down the five biggest takeaways from the report, why CISOs reject traditional platforms, and how automated evidence collection solves the auditor format problem. ### Why SOC 2 Auditors Reject GRC Platform Evidence and Require Screenshots *Published: 2026-03-22 | Source: https://screenata.com/resources/blog/why-soc-2-auditors-reject-grc-platform-evidence-and-require-screenshots.md* Yes, auditors frequently reject API-generated data from GRC platforms. They require timestamped screenshots and PDF exports to satisfy Information Provided by the Entity (IPE) standards. This article explains the auditor format problem and how to automate SOC 2 evidence collection in the format assessors actually accept. ### The Persona Cliff: How to Automate SOC 2 Evidence Collection When Engineers Build Instead of Buy *Published: 2026-03-21 | Source: https://screenata.com/resources/blog/the-persona-cliff-how-to-automate-soc-2-evidence-collection-when-engineers-build-instead-of-buy.md* The State of GRC 2026 survey reveals a massive divide in compliance tooling. At high technical skill levels, GRC practitioners buy commercial platforms while security engineers build their own. This article explains the Persona Cliff, why engineers reject traditional tools for SOC 2 audits, and how to automate evidence collection without maintaining custom scripts. ### How to Read a SOC 2 Report: Structure, Sections, and What to Look For *Published: 2026-03-20 | Source: https://screenata.com/resources/blog/how-to-read-a-soc-2-report-structure-sections-and-what-to-look-for.md* SOC 2 reports follow a specific structure defined by the AICPA. This guide breaks down each section, explains who writes what, and shows you exactly what to look for when evaluating a vendor's report or preparing your own. ### The GRC Skills Gap: Automating SOC 2 Evidence Collection (Avg Skill 5.4/10) *Published: 2026-03-20 | Source: https://screenata.com/resources/blog/the-grc-skills-gap-is-real-automating-soc-2-evidence-collection-with-screenshots-average-skill-5410.md* The State of GRC 2026 survey reveals the average compliance practitioner's technical skill is 5.4 out of 10. This explains why teams struggle with SOC 2 evidence automation. When platforms require custom API scripts to capture screenshots and documentation, mid-skill practitioners get stuck. ### Why CISOs Don't Trust Commercial GRC Tools for SOC 2 Evidence (73.6% Use None) *Published: 2026-03-19 | Source: https://screenata.com/resources/blog/why-cisos-don.md* 73.6% of CISOs use no commercial GRC tool for SOC 2 audits. Instead of buying platforms, highly technical security leaders rely on custom builds and open source because traditional tools fail to automate the actual screenshot evidence collection auditors require. ### 59% of GRC Teams Have No Commercial Tool, What the State of GRC 2026 Survey Reveals *Published: 2026-03-18 | Source: https://screenata.com/resources/blog/59-percent-of-grc-teams-have-no-commercial-tool.md* The largest independent survey of GRC practitioners (795 respondents) found that 59% use spreadsheets, Jira, open source, or nothing at all. No vendor holds above 18% market share. This isn't a market share fight, it's a market creation problem. ### Why Spreadsheets Still Win in GRC (and How to Finally Move Past Them) *Published: 2026-03-18 | Source: https://screenata.com/resources/blog/why-spreadsheets-still-win-in-grc.md* 93 practitioners in the State of GRC 2026 survey use spreadsheets as their primary compliance tool, more than any commercial vendor. The switching cost isn't price. It's confidence. Here's what the data says about why spreadsheets persist and what actually gets teams to move. ### 1 in 5 GRC Teams Is a Single Person, How Solo Practitioners Handle Compliance *Published: 2026-03-17 | Source: https://screenata.com/resources/blog/1-in-5-grc-teams-is-one-person.md* 18% of GRC practitioners run the entire compliance function alone, and 42% of them have zero tooling. The State of GRC 2026 survey reveals what solo practitioners actually use, what they skip, and why automation isn't optional when you're the only person on the team. ### How to Automate CMMC 2.0 Level 2 Evidence Collection with Screenshots *Published: 2026-03-17 | Source: https://screenata.com/resources/blog/how-to-automate-cmmc-20-level-2-evidence-collection-with-screenshots.md* CMMC 2.0 Level 2 assessments require specific visual evidence and screenshots to satisfy NIST 800-171A objectives. This guide explains how to automate CMMC 2.0 evidence collection for DoD compliance, what C3PAO assessors actually check, and where traditional tools fall short. ### How to Automate FedRAMP Evidence Collection with Screenshots *Published: 2026-03-16 | Source: https://screenata.com/resources/blog/how-to-automate-fedramp-evidence-collection-with-screenshots.md* FedRAMP compliance requires extensive evidence documentation across NIST 800-53 Rev 5 control families. This guide explains how to automate FedRAMP evidence collection with screenshots to satisfy 3PAO assessors and maintain federal cloud security during monthly continuous monitoring. ### How to Automate DORA and NIS 2 Evidence Collection Using SOC 2 Overlap *Published: 2026-03-15 | Source: https://screenata.com/resources/blog/how-to-automate-dora-and-nis-2-evidence-collection-using-soc-2-overlap.md* DORA and NIS 2 compliance require strict proof of operational resilience that goes beyond standard SOC 2 policies. This guide explains how to map your existing SOC 2 controls to EU cybersecurity regulations and automate the visual evidence collection required for incident response and third-party risk management. ### How to Automate Vendor Access Control Evidence for SOC 2 and ISO 27001 *Published: 2026-03-14 | Source: https://screenata.com/resources/blog/how-to-automate-vendor-access-control-evidence-for-soc-2-and-iso-27001.md* Yes, you can automate vendor access management evidence. While APIs track internal employees well, third-party access often requires manual screenshots of guest lists and repository permissions. This guide explains how to automate evidence collection for SOC 2 and ISO 27001 vendor controls. ### Automating Multi-Framework Control Mapping for SOC 2, ISO 27001, and HIPAA *Published: 2026-03-13 | Source: https://screenata.com/resources/blog/how-to-automate-multi-framework-control-mapping-and-evidence-collection-across-soc-2-iso-27001-and-hipaa.md* Yes. You can map a single piece of screenshot evidence to satisfy SOC 2, ISO 27001, and HIPAA requirements simultaneously. This guide explains how multi-framework compliance works, which controls overlap, and how to automate evidence collection so you don't capture the same data three times. ### How to Automate CMMC Level 2 Evidence Collection with Screenshots *Published: 2026-03-12 | Source: https://screenata.com/resources/blog/how-to-automate-cmmc-level-2-evidence-collection-with-screenshots.md* CMMC Level 2 assessments require strict documentation across 110 NIST 800-171 practices. This guide explains how to automate CMMC evidence collection using AI agents to capture screenshots and validate controls, reducing the manual prep work required for C3PAO audits. ### How to Automate HIPAA Administrative and Technical Safeguard Evidence with Screenshots *Published: 2026-03-11 | Source: https://screenata.com/resources/blog/how-to-automate-hipaa-administrative-and-technical-safeguard-evidence-with-screenshots.md* Yes. You can automate HIPAA administrative and technical safeguard evidence by capturing system screenshots, validating access controls, and generating audit-ready documentation. This guide explains how automated evidence collection works for HIPAA and where traditional tools fall short. ### How to Automate ISO 27001 Annex A Evidence Collection with Screenshots *Published: 2026-03-10 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-annex-a-evidence-collection-with-screenshots.md* ISO 27001 auditors require specific evidence for every Annex A control in your Statement of Applicability. This guide explains how to automate ISO 27001 evidence collection using screenshots to capture application-level workflows that traditional tools miss. ### How to Automate SOC 2 Asset Inventory Evidence Collection *Published: 2026-03-09 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-asset-inventory-evidence-collection.md* SOC 2 auditors require complete asset inventory evidence to verify your security controls cover all hardware and software. This guide explains how to automate asset management documentation and where traditional GRC tools fall short. ### What Is Continuous Control Monitoring and How Does It Reduce Audit Risk? *Published: 2026-03-08 | Source: https://screenata.com/resources/blog/what-is-continuous-control-monitoring-and-how-does-it-reduce-audit-risk.md* Continuous Control Monitoring (CCM) shifts compliance from annual sampling to automated, daily validation of security controls. By detecting failures immediately rather than months later, CCM drastically reduces the risk of qualified audit opinions and remediation scrambles during SOC 2 and ISO 27001 assessments. ### Building a Trust Center Evidence Library: What Documentation Auditors Actually Need *Published: 2026-03-07 | Source: https://screenata.com/resources/blog/building-a-trust-center-evidence-library-what-documentation-auditors-actually-need.md* Auditors and enterprise security teams don't want marketing summaries; they want raw policy documents, penetration test reports, and architecture diagrams. This guide outlines exactly which security documentation belongs in your Trust Center to satisfy auditor requests and customer due diligence. ### How to Prepare Screenshots for Security Questionnaire Responses *Published: 2026-03-06 | Source: https://screenata.com/resources/blog/how-to-prepare-screenshots-for-security-questionnaire-responses.md* Security questionnaires often require more than just text answers, they demand visual proof. This guide explains how to prepare, sanitize, and automate screenshot evidence for VSAQ, SIG, and CAIQ responses to speed up deal cycles. ### Automating the Last Mile of Compliance Evidence: Beyond GRC Tools *Published: 2026-03-05 | Source: https://screenata.com/resources/blog/automating-the-last-mile-of-compliance-evidence-beyond-grc-tools.md* GRC platforms automate infrastructure monitoring, but the 'last mile' of compliance, screenshots, UI-based settings, and manual workflows, often remains a manual burden. This guide explains how to automate the final 10% of evidence collection for SOC 2 and ISO 27001 to ensure full audit readiness. ### How Screenata Ensures Accuracy and Traceability in Automated Audit Evidence *Published: 2026-03-04 | Source: https://screenata.com/resources/blog/how-screenata-ensures-accuracy-and-traceability-in-automated-audit-evidence.md* Auditors require proof that automated evidence hasn't been tampered with. Screenata ensures accuracy and traceability by capturing immutable metadata, cryptographic hashes, and direct source links for every screenshot and log, creating a verifiable chain of custody that exceeds manual reporting standards. ### The MSP Guide to Scaling PCI DSS Audits Across Clients with Automation *Published: 2026-03-03 | Source: https://screenata.com/resources/blog/the-msp-guide-to-scaling-pci-dss-audits-across-clients-with-automation.md* Managing PCI DSS compliance for multiple clients usually means drowning in spreadsheets and manual screenshots. This guide explains how MSPs can standardize evidence collection, automate Requirement 10 and 11 checks, and scale audit preparation without hiring more staff. ### How to Automate Evidence for "Not Monitored" Controls in Drata *Published: 2026-03-02 | Source: https://screenata.com/resources/blog/how-to-automate-evidence-for-.md* Drata's "Not Monitored" controls require manual evidence uploads, creating a bottleneck for SOC 2 and ISO 27001 audits. This guide explains how to automate evidence collection for these custom controls using screenshot automation and the Drata API. ### How to Document PAN Truncation Evidence for PCI DSS Requirement 3.4.1 *Published: 2026-03-01 | Source: https://screenata.com/resources/blog/how-to-document-pan-truncation-evidence-for-pci-dss-requirement-341.md* PCI DSS auditors require visual proof that Primary Account Numbers (PAN) are truncated when displayed and stored. This guide explains how to capture database screenshots, API logs, and user interface evidence to satisfy Requirement 3.4.1 (formerly 3.3) without exposing sensitive data. ### PCI DSS vs. SOC 2 Evidence: What Documentation Can You Actually Reuse? *Published: 2026-02-28 | Source: https://screenata.com/resources/blog/pci-dss-vs-soc-2-evidence-what-documentation-can-you-actually-reuse.md* Yes, you can reuse about 60-70% of your evidence between PCI DSS and SOC 2, but the format matters. This guide maps the evidence overlap for access control, change management, and logging, and explains why a PCI ROC isn't enough for a SOC 2 auditor. ### SOC 2 Evidence Library Best Practices: Organizing Documentation for Auditors *Published: 2026-02-27 | Source: https://screenata.com/resources/blog/soc-2-evidence-library-best-practices-organizing-documentation-for-auditors.md* A disorganized evidence library leads to IPE failures and extended audit timelines. This guide explains how to structure folders, standardize naming conventions, and automate evidence collection to ensure auditors accept your documentation without pushback. ### How to Document SOC 2 Endpoint Security with MDM Screenshots *Published: 2026-02-26 | Source: https://screenata.com/resources/blog/how-to-document-soc-2-endpoint-security-with-mdm-screenshots.md* SOC 2 auditors require more than a device list; they need proof that endpoint security policies are configured correctly. This guide explains the specific MDM screenshots required for controls CC6.1 and CC6.8, distinguishing between population evidence and configuration evidence. ### How to Automate SOC 2 CC9.2 Vendor Risk Assessments Beyond Questionnaires *Published: 2026-02-25 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-cc92-vendor-risk-assessments-beyond-questionnaires.md* SOC 2 CC9.2 requires more than just collecting vendor reports; it demands proof of review and risk analysis. This guide explains how to automate vendor risk management evidence, including public trust centers and internal review workflows, where traditional GRC questionnaires fall short. ### Vendor Security Assessment Checklist: What Enterprise Teams Actually Evaluate *Published: 2026-02-25 | Source: https://screenata.com/resources/blog/vendor-security-assessment-checklist-what-enterprise-teams-actually-evaluate.md* Enterprise security teams look beyond the SOC 2 badge. They evaluate specific controls around data isolation, fourth-party risk, and SDLC security. This guide breaks down the actual checklist procurement teams use to approve or reject vendors. ### Do You Actually Need a vCISO for SOC 2? (Probably Not Anymore) *Published: 2026-02-24 | Source: https://screenata.com/resources/blog/do-you-actually-need-a-vciso-for-soc-2-probably-not-anymore.md* For most B2B SaaS companies, no. AI compliance tools now handle scoping, policy writing, evidence collection, and audit prep end-to-end. This guide breaks down which SOC 2 tasks are fully automated and the few scenarios where a human consultant still matters. ### SOC 2 for First-Timers: What to Read, What to Skip, and What to Tell Your CEO *Published: 2026-02-24 | Source: https://screenata.com/resources/blog/soc-2-for-first-timers-what-to-read-what-to-skip-and-what-to-tell-your-ceo.md* Someone just asked you for SOC 2. Before you spend a week Googling, here's the official documentation that actually matters, what you can safely ignore, and a plain-English brief you can hand to management so they understand what they're signing up for. ### Why Your ChatGPT SOC 2 Policies Will Fail the Audit *Published: 2026-02-24 | Source: https://screenata.com/resources/blog/why-chatgpt-soc-2-policies-fail-audits.md* ChatGPT can generate professional-looking SOC 2 policies in minutes. The problem is they describe a company that doesn't exist. Here's how that creates audit exceptions, what auditors actually do with your policies, and what to do instead. ### The 7 Documents Your Auditor Actually Needs (And How to Generate Them) *Published: 2026-02-23 | Source: https://screenata.com/resources/blog/the-7-documents-your-auditor-actually-needs-and-how-to-generate-them.md* SOC 2 audits require specific evidence artifacts, not just policy templates. This guide details the 7 critical documents auditors actually review, from system descriptions to evidence samples, and how to automate their generation. ### SOC 2 Evidence by Application Type: SaaS Panels, Internal Tools, and Production Environments *Published: 2026-02-22 | Source: https://screenata.com/resources/blog/soc-2-evidence-by-application-type-saas-panels-internal-tools-and-production-environments.md* Yes, evidence requirements differ significantly by system type. This guide breaks down exactly what screenshots SOC 2 auditors require for SaaS panels, internal admin tools, and cloud infrastructure to ensure audit readiness. ### The Bootstrapped Founder's Guide to SOC 2: What It Actually Costs, Takes, and Whether It's Worth It *Published: 2026-02-22 | Source: https://screenata.com/resources/blog/the-bootstrapped-founders-guide-to-soc-2.md* Request a scoped quote ### How to Run a SOC 2 Readiness Assessment in 2026: The Complete Checklist *Published: 2026-02-21 | Source: https://screenata.com/resources/blog/how-to-run-a-soc-2-readiness-assessment-in-2026-the-complete-checklist.md* A SOC 2 readiness assessment identifies control gaps before your auditor finds them. This guide provides a complete checklist for 2026, explains how to use automation tools like Drata, and highlights the manual evidence often missed during self-assessments. ### What SOC 2 Auditors Actually Look For in Application Evidence *Published: 2026-02-21 | Source: https://screenata.com/resources/blog/what-soc-2-auditors-actually-look-for-in-application-evidence.md* SOC 2 auditors require application evidence that satisfies IPE (Information Produced by the Entity) standards. This guide explains the specific visual criteria, timestamps, URLs, and unique identifiers, that prevent evidence rejection. ### Manual SOC 2 Controls: How to Handle Evidence That Automation Misses *Published: 2026-02-20 | Source: https://screenata.com/resources/blog/manual-soc-2-controls-how-to-handle-evidence-that-automation-misses.md* Most GRC platforms automate infrastructure evidence but leave a gap for application-level controls. This guide explains which SOC 2 controls still require manual screenshots, how to standardize that evidence for auditors, and how AI agents are finally closing the manual gap. ### SOC 2 CC8.1 Evidence Guide: How to Prove Application-Level Change Management *Published: 2026-02-19 | Source: https://screenata.com/resources/blog/soc-2-cc81-evidence-guide-how-to-prove-application-level-change-management.md* Auditors require specific evidence for SOC 2 CC8.1, including tickets, approvals, and testing screenshots. This guide explains how to document application-level changes that API-based automation tools miss. ### SOC 2 CC6.2 Evidence Guide: User Provisioning, Deprovisioning, and Access Reviews *Published: 2026-02-18 | Source: https://screenata.com/resources/blog/soc-2-cc62-evidence-guide-user-provisioning-deprovisioning-and-access-reviews.md* SOC 2 CC6.2 requires evidence for the entire user lifecycle, from onboarding to termination. This guide explains exactly what screenshots and documentation auditors require for user access reviews, provisioning tickets, and revocation logs, and how to automate the collection process. ### SOC 2 CC6.1 Evidence Guide: The Screenshots Auditors Actually Need for Access Control *Published: 2026-02-17 | Source: https://screenata.com/resources/blog/soc-2-cc61-evidence-guide-the-screenshots-auditors-actually-need-for-access-control.md* SOC 2 CC6.1 requires proof of logical access controls across all systems, not just those with API integrations. This guide details the specific screenshots, ticket workflows, and configuration evidence needed for user provisioning, RBAC, and MFA to satisfy auditors. ### How Much Time Does SOC 2 Audit Preparation Actually Take? (Hours vs. Months) *Published: 2026-02-16 | Source: https://screenata.com/resources/blog/how-much-time-does-soc-2-audit-preparation-actually-take-hours-vs-months.md* SOC 2 prep typically spans 3-6 months for Type 1 and 6-12 months for Type 2, but the actual labor hours vary significantly based on tooling. This guide breaks down the engineering time required for remediation, policy work, and manual evidence collection. ### SOC 2 Screenshot Evidence: What Auditors Accept, What Gets Rejected, and How Many You Need *Published: 2026-02-15 | Source: https://screenata.com/resources/blog/soc-2-screenshot-evidence-what-auditors-accept-what-gets-rejected-and-how-many-you-need.md* SOC 2 auditors require specific metadata, timestamps, and context in screenshot evidence. This guide breaks down acceptance criteria, AICPA sampling sizes, and how to automate evidence collection to prevent audit rejection. ### AI Agents vs. API Integrations: The New Stack for SOC 2 Evidence *Published: 2026-02-14 | Source: https://screenata.com/resources/blog/ai-agents-vs-api-integrations-the-new-stack-for-soc-2-evidence.md* Compliance automation has evolved beyond simple API connections. While APIs handle infrastructure monitoring, AI agents now capture the application-level screenshots required for SOC 2 evidence. This guide compares the two technologies and explains how to build a hybrid stack for complete audit automation. ### The vCISO’s Guide to Automating Audit Prep Across Portfolios *Published: 2026-02-13 | Source: https://screenata.com/resources/blog/the-vcisos-guide-to-automating-audit-prep-across-portfolios.md* Managing compliance for multiple clients breaks down when you hit the evidence collection phase. This guide explains how vCISOs automate manual screenshots and audit prep to protect margins and scale their practice. ### How MSPs Automate Compliance Evidence Collection for Multiple Clients *Published: 2026-02-12 | Source: https://screenata.com/resources/blog/how-msps-automate-compliance-evidence-collection-for-multiple-clients.md* MSPs often struggle to scale compliance services due to the manual labor of collecting evidence. This article explains how to automate evidence collection for SOC 2 and HIPAA across multiple clients using AI agents, reducing the need for linear headcount growth. ### Automating CMMC Level 2 Evidence Collection: What APIs Can't Capture *Published: 2026-02-11 | Source: https://screenata.com/resources/blog/automating-cmmc-level-2-evidence-collection-what-apis-can.md* CMMC Level 2 assessments require objective evidence that goes beyond API-based configuration checks. This article explains why C3PAO assessors demand screenshots for application-level controls and how to automate CMMC level 2 evidence collection for hybrid environments. ### How to Capture HIPAA Evidence for EHR Access Logs and Admin Panels *Published: 2026-02-10 | Source: https://screenata.com/resources/blog/how-to-capture-hipaa-evidence-for-ehr-access-logs-and-admin-panels.md* HIPAA audits require more than just raw log data; they demand proof that your logging configuration is active, tamper-proof, and retaining data correctly. This guide explains the specific screenshots and evidence artifacts auditors need for EHR access logs and how to automate their collection. ### How to Bridge the Drata Automation Gap for SOC 2 Evidence *Published: 2026-02-09 | Source: https://screenata.com/resources/blog/how-to-bridge-the-drata-automation-gap-for-soc-2-evidence.md* Drata automates infrastructure compliance via APIs, but application-layer evidence and periodic attestations stay manual. This guide explains how Vera, an agent that runs continuous compliance, does the work a dashboard only flags: capturing application evidence, chasing sign-offs, and filing signed, traceable packs, alongside Drata or in place of it. ### SOC 2 Type 2 Quarterly Evidence Checklist: What to Collect and When *Published: 2026-02-09 | Source: https://screenata.com/resources/blog/soc-2-type-2-quarterly-evidence-checklist-what-to-collect-and-when.md* A SOC 2 Type 2 audit requires evidence of operating effectiveness over a 6-12 month period. This guide outlines the specific quarterly evidence, like user access reviews and vulnerability scans, that you must collect to avoid audit exceptions. ### How to Audit SaaS Vendor Access Controls and Incident Response *Published: 2026-02-08 | Source: https://screenata.com/resources/blog/how-to-audit-saas-vendor-access-controls-and-incident-response.md* Auditing SaaS vendor security requires more than collecting a SOC 2 report. This guide explains how to verify specific access control and incident response evidence within vendor documentation to satisfy SOC 2 CC9.2 and ISO 27001 A.5.19 requirements. ### How to Document ISO 27001 A.6 People Controls with Evidence *Published: 2026-02-07 | Source: https://screenata.com/resources/blog/how-to-document-iso-27001-a6-people-controls-with-evidence.md* ISO 27001 A.6 controls require specific evidence for screening, training, and offboarding. This guide explains exactly what documents auditors accept for People Controls and how to automate evidence collection without exposing sensitive HR data. ### SOC 2 Evidence Preparation Checklist: How to Automate Screenshots Before an Audit *Published: 2026-02-02 | Source: https://screenata.com/resources/blog/soc-2-evidence-preparation-checklist-how-to-automate-screenshots-before-an-audit.md* SOC 2 evidence prep fails on the artifacts, not the policies. This checklist covers what auditors request domain by domain, from CC6 access controls to CC8 change management, and shows how Vera collects most of it through scans, captures the application-level screenshots APIs cannot reach, and chases the attestations only a person can answer. ### How to Document GitHub Access Controls for SOC 2 with Screenshots *Published: 2026-01-29 | Source: https://screenata.com/resources/blog/how-to-document-github-access-controls-for-soc-2-with-screenshots.md* SOC 2 audits require proof that GitHub access is restricted, reviewed, and managed securely. While API tools monitor settings, auditors often demand screenshots for access reviews, negative testing, and pull request samples. This guide explains how to automate GitHub evidence collection for controls CC6.1 and CC7.2. ### Financial Services HITRUST Certification: Complete Evidence Guide *Published: 2026-01-28 | Source: https://screenata.com/resources/blog/financial-services-hitrust-certification-complete-evidence-guide.md* Financial services firms pursuing HITRUST r2 certification face rigorous evidence requirements across 19 control domains. This guide details the exact documentation, screenshots, and operational logs assessors require and explains how to automate evidence collection to reduce audit preparation time. ### How to Automate ISO 27001 Annex A Control Evidence with Screenshots *Published: 2026-01-26 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-annex-a-control-evidence-with-screenshots.md* ISO 27001 certification requires concrete evidence for every applicable Annex A control. This guide explains how to automate the collection of screenshots, logs, and workflow documentation to ensure your ISMS is audit-ready for Stage 2. ### How to Automate ISO 27001 Control Testing with Screenshots *Published: 2026-01-26 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-control-testing-with-screenshots.md* ISO 27001 certification requires documented evidence for every applicable Annex A control in your Statement of Applicability. This guide explains how to automate ISO 27001 control testing using AI-driven screenshots to reduce Stage 2 audit preparation time by 75%. ### How to Automate ISO 27001 Incident Response Evidence with Screenshots *Published: 2026-01-26 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-incident-response-evidence-with-screenshots.md* ISO 27001 certification requires proof that you can detect, report, and learn from security incidents. This guide explains how to automate evidence collection for Annex A incident response controls using workflow recorders to document drills and actual events. ### How to Automate HITRUST r2 Evidence Collection in 2026 *Published: 2026-01-25 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-r2-evidence-collection-in-2026.md* HITRUST r2 assessments require comprehensive evidence documentation across 19 control domains. This guide explains how to automate HITRUST evidence collection, capturing screenshots and workflows to reduce assessment preparation from months to weeks. ### How to Combine ISO 27001 and HIPAA Evidence with Automated Screenshots *Published: 2026-01-24 | Source: https://screenata.com/resources/blog/how-to-combine-iso-27001-and-hipaa-evidence-with-automated-screenshots.md* Yes, healthcare organizations can satisfy both ISO 27001 and HIPAA requirements with a single automated evidence workflow. This guide explains how to capture audit-ready screenshots that map Annex A controls to HIPAA safeguards while automatically redacting PHI. ### How to Automate HITRUST r2 Evidence Collection for SaaS Vendors *Published: 2026-01-20 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-r2-evidence-collection-for-saas-vendors.md* SaaS vendors selling to healthcare face rigorous HITRUST r2 evidence requirements across 19 control domains. This guide explains how to automate HITRUST CSF evidence collection, including screenshots and workflow recordings, to reduce assessment preparation time from 9 months to 8 weeks. ### AWS SOC 2 Compliance Checklist: Complete Evidence Guide *Published: 2026-01-19 | Source: https://screenata.com/resources/blog/aws-soc-2-compliance-checklist-complete-evidence-guide.md* This guide provides a comprehensive AWS SOC 2 compliance checklist, detailing the exact evidence, logs, and screenshots auditors require. Learn how to automate evidence collection for AWS controls and close the gap between infrastructure monitoring and audit-ready documentation. ### How to Automate HITRUST Third-Party Risk Management Evidence *Published: 2026-01-19 | Source: https://screenata.com/resources/blog/how-to-automate-hitrust-third-party-risk-management-evidence.md* HITRUST r2 assessments require rigorous evidence for Domain 05 (Third-Party Security). This guide explains how to automate the collection of vendor risk assessments, SOC 2 report validation, and contract review evidence to reduce HITRUST audit preparation time by 90%. ### Manual Workpapers vs Integrated Audit Workflows: A Complete Comparison *Published: 2026-01-19 | Source: https://screenata.com/resources/blog/manual-workpapers-vs-integrated-audit-workflows-a-complete-comparison.md* Integrated audit workflows replace static spreadsheets with dynamic, automated evidence collection. This comparison details how automating internal audit workpapers reduces testing time by 92% and ensures compliance with 2026 IIA Standards. ### How to Document ISO 27001 A.7 Physical Controls with Evidence *Published: 2026-01-18 | Source: https://screenata.com/resources/blog/how-to-document-iso-27001-a7-physical-controls-with-evidence.md* ISO 27001 A.7 physical controls require concrete evidence of secure perimeters, entry logs, and equipment protection. This guide explains how to collect and automate audit-ready documentation for physical security, whether you manage a data center or a fully remote team. ### How to Automate SOC 2 Vendor Assessments with Evidence Screenshots *Published: 2026-01-17 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-vendor-assessments-with-evidence-screenshots.md* SOC 2 vendor assessments (CC9.2) require evidence of risk reviews, security report analysis, and ongoing monitoring. This guide explains how to automate vendor risk management (TPRM) evidence collection to reduce manual review time by 90%. ### How to Automate ISO 27001 Supplier Security Evidence (A.5.19-A.5.23) *Published: 2026-01-16 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-supplier-security-evidence-a519-a523.md* ISO 27001 supplier security evidence requires documenting vendor risk assessments, agreements, and ongoing monitoring for Annex A controls A.5.19–A.5.23. This guide explains how to automate the collection of screenshots and workflow records to ensure your supply chain security is audit-ready. ### How to Prove Application Access Restrictions for SOC 2 with Screenshots *Published: 2026-01-16 | Source: https://screenata.com/resources/blog/how-to-prove-application-access-restrictions-for-soc-2-with-screenshots.md* Proving application access restrictions for SOC 2 requires concrete screenshot evidence of 'access denied' states, not just policy documents. This article explains how to automate negative testing for Control CC6.1, capturing valid proof that unauthorized users are blocked from sensitive data. ### What Auditors Expect for SOC 2 Change Approval Evidence with Screenshots *Published: 2026-01-16 | Source: https://screenata.com/resources/blog/what-auditors-expect-for-soc-2-change-approval-evidence-with-screenshots.md* SOC 2 auditors require specific evidence for change approvals, including pull request screenshots, ticket authorization, and deployment logs. This guide explains exactly what evidence to collect for CC8.1 and how to automate the documentation process. ### How to Automate Internal Audit Evidence Collection in 2026 *Published: 2026-01-15 | Source: https://screenata.com/resources/blog/how-to-automate-internal-audit-evidence-collection.md* Internal auditors spend 40% of their time on manual procedural tasks. This guide shows how to automate internal audit evidence collection using AI-powered tools, turning workpaper preparation from 60+ hours of manual capture per audit into review and approval. Learn step-by-step techniques for automating control testing, evidence capture, and workpaper generation that comply with the 2026 Global Internal Audit Standards. ### How to Use HITRUST to Prove HIPAA Compliance with Automated Evidence *Published: 2026-01-15 | Source: https://screenata.com/resources/blog/how-to-use-hitrust-to-prove-hipaa-compliance-with-automated-evidence.md* HITRUST CSF certification is the gold standard for proving HIPAA compliance, but it requires rigorous evidence documentation. This guide explains how health systems can automate the collection of screenshots and implementation evidence to satisfy both HITRUST assessors and HIPAA auditors. ### How to Automate EU AI Act Compliance Evidence for Internal Audits *Published: 2026-01-14 | Source: https://screenata.com/resources/blog/how-to-automate-eu-ai-act-compliance-evidence-for-internal-audits.md* Internal auditors can automate EU AI Act evidence collection by using AI agents to capture technical documentation, validation logs, and screenshots of human oversight controls. This guide explains how to streamline compliance for High-Risk AI systems and reduce manual documentation efforts. ### Drata SOC 2 Manual Work: The Evidence You Still Collect Yourself *Published: 2026-01-13 | Source: https://screenata.com/resources/blog/drata-automate-soc-2-what-you-still-need-to-do-manually.md* Drata automates infrastructure and policy tracking over API, then hands back the application controls, the change approvals, and the access reviews. This is the specific list of SOC 2 work a dashboard still leaves on your plate for controls like CC6.1 and CC8.1, how long each task takes, and how Vera, an agent who runs continuous compliance, does that work instead. ### How to Automate SOC 2 Evidence for Multi-Tenant Applications with Screenshots *Published: 2026-01-13 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-for-multi-tenant-applications-with-screenshots.md* Multi-tenant SaaS platforms require rigorous evidence to prove data isolation during SOC 2 audits. This guide explains how to automate evidence collection for tenant separation controls using screenshots and workflow recording, ensuring you pass CC6.1 and CC6.7 without manual sampling. ### AI Agents vs RPA: Which is Better for Compliance Automation? *Published: 2026-01-12 | Source: https://screenata.com/resources/blog/ai-agents-vs-rpa-which-is-better-for-compliance-automation.md* Choosing between AI agents and RPA for compliance automation depends on the complexity of your workflows. While RPA excels at high-volume, static tasks, AI agents are superior for compliance evidence collection because they handle dynamic UI changes, perform autonomous reasoning, and close the 20% manual gap in SOC 2 and ISO 27001 audits. ### How Teams Extend Drata to Fully Pass SOC 2 with Automated Evidence *Published: 2026-01-12 | Source: https://screenata.com/resources/blog/how-teams-extend-drata-to-fully-pass-soc-2-with-automated-evidence.md* Drata automates infrastructure monitoring, but SOC 2 audits still require application evidence and periodic attestations it can only flag. This guide explains how Vera, an agent that runs continuous compliance, does that work: capturing application evidence, chasing sign-offs, and filing signed, traceable packs, alongside Drata or in place of it. ### How the New IIA Standards Change Evidence Documentation Requirements *Published: 2026-01-10 | Source: https://screenata.com/resources/blog/how-the-new-iia-standards-change-evidence-documentation-requirements.md* The new Global Internal Audit Standards (GIAS) mandate stricter requirements for evidence reliability, relevance, and sufficiency. This article explains how the 2025 standards impact audit documentation and why manual screenshots often fail to meet the new conformance criteria. ### How to Automate SOC 2 Type II Control Testing with Screenshots *Published: 2026-01-10 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-type-ii-control-testing-with-screenshots.md* SOC 2 Type II audits require proof that controls operated effectively over a period of time. While APIs handle infrastructure, application-level tests often remain manual. Screenata automates SOC 2 control testing by capturing screenshots, validating workflows, and generating audit-ready evidence packs automatically. ### How to Reduce SOC 2 Compliance Costs with Automated Evidence Collection *Published: 2026-01-10 | Source: https://screenata.com/resources/blog/how-to-reduce-soc-2-compliance-costs-with-automated-evidence-collection.md* Manual evidence collection is the hidden driver of high SOC 2 costs. By using automated tools to capture screenshots and generate audit-ready reports, companies can cut a SOC 2 Type II year from about 200 hours of team time to 60-80. This article explains the ROI of evidence automation. ### AI Compliance Officer: What Makes Screenata a Category-Defining Platform *Published: 2026-01-09 | Source: https://screenata.com/resources/blog/compliance-evidence-automation-what-makes-screenata-a-category-defining-platform.md* Screenata defines a new category: an AI Compliance Officer named Vera who runs continuous compliance as an agent. She scans your infrastructure, writes deterministic policies from your real systems, captures the application evidence APIs can't see, chases attestations in Slack, and signs every artifact. ### How to Upload HITRUST Evidence to MyCSF Portal: Best Practices *Published: 2026-01-09 | Source: https://screenata.com/resources/blog/how-to-upload-hitrust-evidence-to-mycsf-portal-best-practices.md* HITRUST MyCSF evidence uploads require strict formatting, naming conventions, and requirement mapping. This guide explains the best practices for preparing and uploading assessor-ready evidence to the MyCSF portal to avoid kickbacks and assessment delays. ### What Evidence Can Be Automated Across SOC 2, ISO 27001, HIPAA, and CMMC with Screenshots? *Published: 2026-01-09 | Source: https://screenata.com/resources/blog/what-evidence-can-be-automated-across-soc-2-iso-27001-hipaa-and-cmmc-with-screenshots.md* Yes. You can now automate evidence collection for access controls, change management, and application workflows across SOC 2, ISO 27001, HIPAA, and CMMC. This article details the specific evidence types that AI tools capture via screenshots and APIs to replace manual audit work. ### The Screenshot Evidence Drata Can't Collect for SOC 2 Audits *Published: 2026-01-08 | Source: https://screenata.com/resources/blog/drata-soc-2-automation-gaps-what-evidence-still-requires-manual-screenshots.md* Your auditor asks for proof of admin-panel permissions, change approvals, and access reviews, and Drata captures none of it. Here are the specific controls (CC6.1, CC7.2, CC8.1) that need visual evidence and human sign-offs, and how Vera, an agent who runs continuous compliance, does that work: capturing UI proof, chasing attestations, and filing signed packs that sync back to Drata. ### How to Standardize Manual SOC 2 Evidence Collection with Screenshots *Published: 2026-01-08 | Source: https://screenata.com/resources/blog/how-to-standardize-manual-soc-2-evidence-collection-with-screenshots.md* Inconsistent SOC 2 evidence causes audit delays and increased sampling. This guide explains how to standardize manual evidence collection across engineering and HR teams using screenshot templates and automation tools to ensure audit readiness. ### HITRUST r2 Assessment Readiness Checklist: Complete Evidence Guide *Published: 2026-01-07 | Source: https://screenata.com/resources/blog/hitrust-r2-assessment-readiness-checklist-complete-evidence-guide.md* Preparing for a HITRUST r2 validated assessment requires rigorous evidence collection across 19 control domains and five maturity levels. This comprehensive checklist details the exact documentation, screenshots, and policy evidence assessors require to achieve certification, and explains how to automate the evidence collection process. ### How to Automate SOC 2 Access Control Evidence Collection with Screenshots *Published: 2026-01-07 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-access-control-evidence-collection-with-screenshots.md* Yes. You can automate access control evidence for SOC 2 audits by using AI agents to capture timestamps, screenshots, and validation steps for logical access tests. This guide explains how to automate evidence for CC6.1, CC6.2, and CC6.3 without manual screenshotting. ### How to Document ISO 27001 Risk Assessment Evidence Automatically *Published: 2026-01-07 | Source: https://screenata.com/resources/blog/how-to-document-iso-27001-risk-assessment-evidence-automatically.md* ISO 27001 risk assessment evidence requires more than a spreadsheet; auditors demand proof of methodology application, risk owner approval, and treatment plan execution. This guide explains how to automate the documentation of risk assessments to satisfy Clause 6.1.2 and 8.2 requirements efficiently. ### Continuous Compliance Evidence Collection Across SOC 2, ISO 27001, HIPAA, and CMMC *Published: 2026-01-06 | Source: https://screenata.com/resources/blog/how-to-automate-continuous-evidence-collection-for-soc-2-iso-27001-hipaa-and-cmmc-with-screenshots.md* Yes. You can automate continuous compliance evidence collection across SOC 2, ISO 27001, HIPAA, and CMMC using AI tools that capture screenshots and validate controls automatically. This article explains how to bridge the 20% manual gap left by traditional GRC tools to maintain audit-ready evidence year-round. ### How to Automate ISO 27001 Evidence Collection in 2026 *Published: 2026-01-05 | Source: https://screenata.com/resources/blog/how-to-automate-iso-27001-evidence-collection-in-2026.md* ISO 27001 certification audits demand evidence for all applicable Annex A controls in your Statement of Applicability. This guide shows how to automate ISO 27001 evidence collection, specifically screenshots and workflow documentation, to reduce Stage 2 audit preparation time by 75%. ### ISO 27001:2022 vs 2013: How to Automate New Evidence Requirements *Published: 2026-01-05 | Source: https://screenata.com/resources/blog/iso-270012022-vs-2013-how-to-automate-new-evidence-requirements.md* ISO 27001:2022 reduces the control count from 114 to 93 but introduces 11 new controls requiring dynamic evidence. This guide explains the key evidence changes, how to document the new 'Technological' theme with screenshots, and how to automate the transition before the October 2025 deadline. ### What Screenshots Are Acceptable for SOC 2 CC6 Controls *Published: 2026-01-05 | Source: https://screenata.com/resources/blog/what-screenshots-are-acceptable-for-soc-2-cc6-controls.md* An acceptable SOC 2 CC6 screenshot shows the system clock, the URL, the logged-in identity, and the specific state that proves the control held, with metadata an auditor can verify. This guide covers the requirements control by control, what gets rejected and why, and how Vera captures application-level access evidence with signed timestamps and DOM snapshots attached. ### The Best AI Tools for Automating SOX ITGC Evidence in 2026 *Published: 2026-01-04 | Source: https://screenata.com/resources/blog/best-practices-for-automating-sox-itgc-evidence-in-2026-from-access-controls-to-continuous-monitoring.md* Compare the best AI tools for automating SOX ITGC evidence in 2026, across access controls, change management, and continuous monitoring. See how AI-driven evidence capture closes the manual 20% that point-in-time audits leave behind. ### How to Automate SOC 2 Evidence Collection *Published: 2026-01-04 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-collection.md* Automating SOC 2 evidence collection involves using AI-driven agents to record application workflows, capture timestamped screenshots, and generate audit-ready PDF evidence packs. This process eliminates the '20% manual gap' left by traditional GRC platforms, reducing audit preparation time from weeks to hours. ### How to Prove Change Management for SOC 2 Without Jira *Published: 2026-01-04 | Source: https://screenata.com/resources/blog/how-to-prove-change-management-for-soc-2-without-jira.md* SOC 2 change management evidence does not require Jira. You can satisfy auditors by automating evidence collection from GitHub, Linear, or Slack using screenshots and workflow recordings. This guide explains how to prove CC7.2 compliance without a traditional ticketing system. ### AI Agents in Compliance: How Screenata is Redefining Evidence Collection in 2026 *Published: 2026-01-03 | Source: https://screenata.com/resources/blog/ai-agents-in-compliance-how-screenata-is-redefining-evidence-collection-in-2026.md* In 2026, AI agents have transformed compliance from manual prep work to autonomous policy writing, evidence collection, and audit readiness. Screenata's AI Compliance Officer uses agentic AI to replace both the GRC platform and the compliance consultant, reducing audit preparation time by 92% through codebase analysis, automated policy drafting, and verifiable evidence packs. ### Does Vanta Take Screenshots for SOC 2? The Complete Guide to Automated Evidence *Published: 2026-01-03 | Source: https://screenata.com/resources/blog/does-vanta-take-screenshots-for-soc-2-the-complete-guide-to-automated-evidence.md* Vanta shipped a computer-use agent in August 2026 that captures screenshots from a cloud browser, so it now takes screenshots of reachable web pages. What it does not reach is your own authenticated application UI, because a cloud browser does not inherit your session. Screenata gives teams a clearer way to prove those controls: Vera collects API evidence, captures UI workflows, chases attestations, signs the proof, and maps each claim to the control it supports. ### How to Detect Changes That Affect SOC 2 Compliance Controls with Automated Evidence *Published: 2026-01-03 | Source: https://screenata.com/resources/blog/how-to-detect-changes-that-affect-soc-2-compliance-controls-with-automated-evidence.md* Detecting changes that affect compliance controls requires continuous monitoring of application workflows, not just infrastructure APIs. This article explains how Screenata detects UI and process changes that impact SOC 2 and ISO 27001 controls, ensuring your evidence remains valid between audits. ### What SOC 2 Application Evidence Do Auditors Require That Drata Cannot Automate? *Published: 2026-01-02 | Source: https://screenata.com/resources/blog/drata-vs-application-level-soc-2-controls-what-auditors-actually-ask-for.md* SOC 2 auditors require application evidence for controls like RBAC, change management, and vulnerability review. Drata monitors infrastructure over API but flags application controls as manual and waits. This article covers what visual proof auditors ask for and how Vera, an agent that runs continuous compliance, captures it and chases the attestations a dashboard can't. ### Third-Party Risk Management Evidence Requirements: How to Automate Vendor Audits *Published: 2026-01-02 | Source: https://screenata.com/resources/blog/third-party-risk-management-evidence-requirements-how-to-automate-vendor-audits.md* Third-party risk management (TPRM) evidence requirements include vendor risk assessments, SOC 2 report reviews, and signed Data Processing Agreements (DPAs). This guide explains exactly what evidence auditors require for SOC 2 CC9 and ISO 27001 A.5 controls and how to automate the collection of vendor due diligence documentation. ### How to Automate Manual SOC 2 Evidence Drata Can't Capture *Published: 2026-01-01 | Source: https://screenata.com/resources/blog/how-to-automate-the-manual-evidence-drata-misses.md* Drata automates about 80% of SOC 2 through APIs, then flags the rest as manual and waits. This guide shows how Vera, an agent that runs continuous compliance, does the work a dashboard leaves behind: capturing application evidence for CC6.1, CC7.2, and CC8.1, chasing the attestations only a person can answer, and filing signed, traceable packs, alongside Drata or in place of it. ### ISO 27001 Statement of Applicability (SoA): Complete Evidence Guide *Published: 2026-01-01 | Source: https://screenata.com/resources/blog/iso-27001-statement-of-applicability-soa-complete-evidence-guide.md* ISO 27001 certification requires proving that every control in your Statement of Applicability (SoA) is implemented and effective. This guide details the exact evidence, screenshots, and logs auditors require for Annex A controls and explains how to automate collection. ### 10 Compliance Automation Trends That Actually Changed in 2025 and Will Matter in 2026 *Published: 2025-12-31 | Source: https://screenata.com/resources/blog/10-compliance-automation-trends-that-actually-changed-in-2025-and-will-matter-in-2026.md* Compliance automation shifted from simple infrastructure monitoring to AI-agentic evidence capture in 2025. Discover the ten trends, including the closure of the '20% manual gap' and automated CMMC 2.0 readiness, that will define the audit landscape in 2026. ### Can Screenata Integrate with Jira, GitHub, or CI/CD for Continuous Compliance? *Published: 2025-12-31 | Source: https://screenata.com/resources/blog/can-screenata-integrate-with-jira-github-or-cicd-for-continuous-compliance.md* Screenata integrates with Jira, GitHub, and CI/CD pipelines to enable continuous compliance by triggering AI-driven evidence collection during the development lifecycle. This integration automates documentation for change management (CC7.2) and access controls (CC6.1), ensuring audit-ready evidence is captured at the moment of action. ### What SOC 2 Evidence Do Auditors Require for Application Controls? *Published: 2025-12-31 | Source: https://screenata.com/resources/blog/soc-2-control-evidence-what-auditors-actually-want-to-see.md* SOC 2 auditors require screenshots for application controls that infrastructure APIs cannot verify, specifically CC6.1 (logical access), CC7.2 (change management), and CC8.1 (vulnerability management). This article explains what evidence auditors want, why infrastructure logs aren't enough, and how to collect audit-ready screenshots with timestamps and metadata. ### How to Collect SOC 2 CC8 Evidence When Changes Are Manual with Screenshots *Published: 2025-12-30 | Source: https://screenata.com/resources/blog/how-to-collect-soc-2-cc8-evidence-when-changes-are-manual-with-screenshots.md* Yes. AI tools can automatically capture SOC 2 CC8 evidence for manual changes by recording workflows, validating screenshots, and generating audit-ready reports. This article explains how to satisfy change management requirements for SaaS configurations and manual processes where traditional GRC automation fails. ### What Auditors Still Ask for After Drata Automation: Missing SOC 2 Evidence *Published: 2025-12-30 | Source: https://screenata.com/resources/blog/what-auditors-still-ask-for-after-drata-automation-missing-soc-2-evidence.md* Drata automates infrastructure over API, then marks the application controls manual and waits. This guide shows what auditors still ask for after Drata (application RBAC proof, change approvals, access reviews) and how Vera, an agent who runs continuous compliance, does that work: capturing UI proof for CC6.1 and CC7.2, chasing the attestations only a person can answer, and filing signed, traceable packs that sync back to Drata. ### HITRUST CSF vs SOC 2: Evidence Requirements Compared *Published: 2025-12-29 | Source: https://screenata.com/resources/blog/hitrust-csf-vs-soc-2-evidence-requirements-compared.md* HITRUST r2 assessments demand significantly more rigorous evidence than SOC 2, requiring documentation across five maturity levels. This guide compares the specific evidence requirements for both frameworks and explains how to automate collection for MyCSF and audit partners. ### How to Achieve 100% SOC 2 Automation with Vanta and Screenshot Tools *Published: 2025-12-29 | Source: https://screenata.com/resources/blog/how-screenata-vanta-gets-you-100-automated-coverage.md* Vanta monitors your infrastructure and leaves the rest to you, which means 40 to 60 hours of evidence chasing per audit. Screenata closes that gap with an agent named Vera who runs the program, collecting infrastructure and application evidence, chasing attestations in Slack, and tracing every artifact back to a control. This guide shows how to reach full coverage, whether you keep Vanta or replace it. ### What Makes SOC 2 Evidence Acceptable to Auditors? Quality Checklist *Published: 2025-12-29 | Source: https://screenata.com/resources/blog/soc-2-evidence-quality-checklist-for-application-controls.md* SOC 2 auditors require screenshots with timestamps, metadata, tester identity, and control mapping, not just static images. This checklist shows what makes SOC 2 evidence acceptable for application controls like CC6.1 and CC7.2, including AICPA standards for sufficiency, reliability, and relevance. ### How Continuous Compliance Automation Reduces Risk of SOC 2 Audit Failure *Published: 2025-12-28 | Source: https://screenata.com/resources/blog/how-continuous-compliance-automation-reduces-risk-of-soc-2-audit-failure.md* Continuous compliance automation eliminates the risk of audit failure by replacing last-minute manual screenshots with always-on evidence capture. This article explains how AI tools automate SOC 2 evidence collection to prevent control drift and missing documentation. ### How Drata Works for SOC 2: Architecture, Integrations, and Limits *Published: 2025-12-28 | Source: https://screenata.com/resources/blog/how-drata-automates-soc-2-and-where-it-stops.md* Drata connects to 75+ integrations via read-only APIs to monitor your infrastructure. This guide explains how Drata's architecture works, which integrations matter most for SOC 2, where the monitoring model hits its limits with application controls and attestations, and how Vera, an agent that runs continuous compliance, does the work a dashboard only flags. ### What Does Automated Evidence Collection Look Like for SOC 2 *Published: 2025-12-25 | Source: https://screenata.com/resources/blog/what-does-automated-evidence-collection-look-like-for-soc-2.md* Automated SOC 2 evidence collection is an agent that captures application tests, screenshots, and metadata, then signs and files them. Screenata's agent Vera runs the test, scores the capture, chases the attestations only a person can answer, and files signed packs that close the 20% gap a dashboard leaves open. ### How to Automate SOC 2 Evidence Collection with Screenshots in 2025 *Published: 2025-12-23 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-collection-in-2025.md* To automate SOC 2 evidence collection, use GRC platforms (Drata, Vanta) for infrastructure APIs (80%) plus screenshot automation for application evidence (20%). This guide shows step-by-step how to automate SOC 2 screenshots, workflow documentation, and audit-ready reports, reducing manual work from 80 hours to 6 hours per audit. ### AI Agents for Compliance: From Manual Evidence to Autonomous Verification Systems *Published: 2025-12-22 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-collection-with-ai-agents-and-screenshots.md* AI agents now do the SOC 2 evidence work a dashboard leaves behind: running control tests, capturing UI proof, chasing the attestations only a person can answer, and filing signed, audit-ready packs. This guide shows how Vera, an agent who runs continuous compliance, moves you from manual evidence to scheduled verification across SOC 2, ISO 27001, and HIPAA, and where honest escalation keeps a human in the loop. ### Integrating Application-Level Evidence Automation with Drata, Vanta & GRC Platforms *Published: 2025-12-20 | Source: https://screenata.com/resources/blog/how-to-automate-soc-2-evidence-collection-with-screenshots-for-drata-and-vanta.md* For teams evaluating Drata, Vanta, and other GRC dashboards, Screenata puts Vera in charge of the evidence work. She collects API evidence, captures UI workflows when screenshots prove what APIs cannot see, chases attestations, signs the proof, maps it across frameworks, and exports only when an existing audit workspace needs the pack. ### Why screenshots and workflow recordings are essential for control validation *Published: 2025-12-20 | Source: https://screenata.com/resources/blog/why-screenshots-and-workflow-recordings-are-essential-for-control-validation.md* Screenshots and workflow recordings provide the visual proof required for application-level control validation, the controls that logs and APIs cannot reach. This guide covers which controls need visual evidence, why recordings carry more integrity than static screenshots, and how an AI compliance agent named Vera captures that proof as one signed input inside a broader evidence program. ### How AI Agents Capture Screenshots Automatically for Audits *Published: 2025-12-18 | Source: https://screenata.com/resources/blog/how-ai-agents-capture-screenshots-automatically-for-audits.md* An AI compliance agent named Vera captures application screenshots as one of several ways she collects audit evidence. She runs the control test, the browser extension captures each step with a DOM snapshot and signed timestamp, a vision model scores whether the shot proves the control, and every capture is mapped to a Trust Services Criterion and signed. This guide covers how that capture works, where it fits in an agent-run program, and what auditors require to accept it. ### What Is Compliance Evidence Automation? How to Automate SOC 2 Evidence with Screenshots *Published: 2025-12-18 | Source: https://screenata.com/resources/blog/what-is-compliance-evidence-automation-how-to-automate-soc-2-evidence-with-screenshots.md* Compliance evidence automation is an agent that collects, documents, and signs SOC 2 evidence across every source: API scans, application screenshots, and the attestations only a person can answer. Screenata's agent Vera runs it, capturing the UI proof a dashboard can't reach, mapping it to controls, and filing signed, traceable packs. ### Why Manual SOC 2 Evidence Collection No Longer Scales for Modern Audits *Published: 2025-12-18 | Source: https://screenata.com/resources/blog/why-manual-soc-2-evidence-collection-no-longer-scales-for-modern-audits.md* Manual SOC 2 evidence collection takes 40–80 hours per quarter, leading to human error and audit delays. Modern audits require automation to capture screenshots and document application-level controls. This article explains why manual methods fail and how automated evidence collection scales compliance for fast-growing companies. ### What makes Screenata a category-defining compliance automation platform *Published: 2025-12-15 | Source: https://screenata.com/resources/blog/what-makes-screenata-a-category-defining-compliance-automation-platform.md* Screenata is an AI Compliance Officer, an agent named Vera who runs continuous compliance. She scans your infrastructure, writes deterministic SOC 2 policies from your real systems, captures the application evidence APIs can't see, chases attestations in Slack, and signs every artifact. A dashboard flags work; Vera does it. ### Can Drata Fully Automate SOC 2? What It Covers and What It Misses *Published: 2025-12-14 | Source: https://screenata.com/resources/blog/can-drata-fully-automate-soc-2-a-practical-breakdown.md* Drata connects to AWS, GitHub, and Okta to monitor infrastructure controls. It does not write policies, capture application evidence, chase attestations, or do the work it flags. This breakdown covers exactly what Drata automates, what it leaves on your plate, and how Vera, an agent that runs continuous compliance, closes the gap alongside Drata or in place of the platform-plus-consultant stack. ### Can One Platform Really Support Multiple Frameworks at Once? *Published: 2025-12-10 | Source: https://screenata.com/resources/blog/can-one-platform-really-support-multiple-frameworks-at-once.md* Yes. Modern compliance automation platforms like Screenata use cross-framework mapping to satisfy SOC 2, ISO 27001, HIPAA, and CMMC requirements simultaneously. By capturing evidence once and mapping it to multiple control IDs, organizations reduce manual audit workloads by up to 80% and eliminate redundant testing. ### How Screenata Enables Continuous, Cross-Framework Compliance Monitoring *Published: 2025-12-06 | Source: https://screenata.com/resources/blog/how-screenata-enables-continuous-cross-framework-compliance-monitoring.md* Screenata enables continuous, cross-framework compliance by acting as your AI Compliance Officer, writing policies, analyzing your codebase, mapping controls, collecting evidence, and tracking readiness across SOC 2, ISO 27001, HIPAA, and more. This approach eliminates redundant manual testing, ensures real-time audit readiness, and reduces documentation effort by over 90%. ### How Screenata Unifies Evidence Across SOC 2, HIPAA, ISO, and CMMC *Published: 2025-12-05 | Source: https://screenata.com/resources/blog/how-screenata-unifies-evidence-across-soc-2-hipaa-iso-and-cmmc.md* Screenata unifies compliance evidence by capturing application-level workflows once and mapping them to multiple frameworks simultaneously. This eliminates redundant documentation for SOC 2, HIPAA, ISO 27001, and CMMC, reducing audit preparation time by up to 90% through AI-powered cross-framework mapping. ### Why Continuous Evidence Collection is Becoming a Regulatory Expectation *Published: 2025-12-02 | Source: https://screenata.com/resources/blog/why-continuous-evidence-collection-is-becoming-a-regulatory-expectation.md* Regulatory bodies like the AICPA, SEC, and NIST are shifting from 'point-in-time' audits to continuous monitoring. Continuous evidence collection ensures security controls remain functional 24/7, eliminating the compliance gap caused by rapid digital changes and providing real-time audit readiness. ### Why Do Auditors Trust Screenata-Generated Evidence Packs? *Published: 2025-11-27 | Source: https://screenata.com/resources/blog/why-do-auditors-trust-screenata-generated-evidence-packs.md* Auditors trust Screenata-generated evidence packs because they provide verifiable, immutable, and contextual proof of control execution. By combining timestamped screenshots with system metadata, user identity, and professional formatting, Screenata eliminates the risk of human error and evidence tampering common in manual collection. ### The ROI of Compliance Evidence Automation: Accuracy, Speed, and Audit Readiness *Published: 2025-11-26 | Source: https://screenata.com/resources/blog/the-roi-of-compliance-evidence-automation-accuracy-speed-and-audit-readiness.md* Compliance evidence automation delivers a 90-95% cut in manual effort by running the control test, scoring the capture, chasing attestations, and signing the pack. ### Why Manual Evidence Collection No Longer Scales for Modern Audits *Published: 2025-11-15 | Source: https://screenata.com/resources/blog/why-manual-evidence-collection-fails.md* Here's why automation is no longer optional. ### What Makes Screenata a Category-Defining AI Compliance Officer *Published: 2025-11-12 | Source: https://screenata.com/resources/blog/what-makes-screenata-category-defining.md* Screenata defines a new category: an AI Compliance Officer named Vera who runs continuous compliance as an agent. She scans your infrastructure, writes deterministic policies from your real systems, captures the application evidence a dashboard can't, chases attestations in Slack, and signs every artifact. ### What Computer-Use-Level Verification Means for Audit Reliability *Published: 2025-11-11 | Source: https://screenata.com/resources/blog/what-computer-use-verification-means-audit-reliability.md* Computer-use AI enables 99%+ audit reliability by autonomously testing any web interface without APIs. This breakthrough eliminates API integration gaps, reduces false negatives from 15% to <1%, and enables continuous compliance monitoring for legacy systems. ### Your GRC Integrations Are Connected. Why Are You Still Collecting Evidence by Hand? *Published: 2025-11-07 | Source: https://screenata.com/resources/blog/what-is-compliance-evidence-automation.md* API integrations leave gaps in audit evidence collection. See how screenshot and procedure automation captures the work that still happens on screen. ### Is Drata Enough to Automate SOC 2 Compliance Completely? *Published: 2025-11-02 | Source: https://screenata.com/resources/blog/is-drata-enough-to-automate-soc-2-end-to-end.md* No. Drata automates about 80% of SOC 2 through infrastructure APIs, then flags the rest and waits for you. This article explains what Drata automates, the 20% it leaves manual (application screenshots plus the attestations only a person can answer), and how Vera, an agent that runs continuous compliance, closes the gap alongside Drata or in place of the platform-plus-consultant stack. ### Will AI Agents Eventually Handle Full Compliance Testing? *Published: 2025-11-02 | Source: https://screenata.com/resources/blog/will-ai-agents-handle-full-compliance-testing.md* Yes. AI agents will handle 80-90% of compliance testing autonomously, executing control tests, generating evidence, and detecting failures. Human oversight shifts from test execution to strategic risk management. ### How Screenata Fits Into the Next Generation of Audit Automation *Published: 2025-10-30 | Source: https://screenata.com/resources/blog/how-screenata-fits-next-generation-audit-automation.md* Screenata is an AI Compliance Officer for startups, handling policy writing, codebase analysis, control mapping, evidence collection, and readiness scoring. It's evolving toward autonomous compliance testing with continuous monitoring, predictive compliance, and self-healing workflows. ### Can AI Achieve Real-Time Compliance Assurance Across Multiple Standards? *Published: 2025-10-28 | Source: https://screenata.com/resources/blog/can-ai-achieve-real-time-compliance-multiple-standards.md* Yes. AI can monitor SOC 2, ISO 27001, HIPAA, and PCI-DSS simultaneously in real-time, providing continuous compliance status instead of quarterly snapshots. This significantly reduces multi-framework audit costs while improving coverage from quarterly snapshots to continuous verification. ### How to Document SOC 2 Application Testing Automatically with Screenshots *Published: 2025-10-24 | Source: https://screenata.com/resources/blog/document-application-level-tests-rbac.md* Automate SOC 2 application testing documentation by using browser extensions that capture screenshots during RBAC tests, access denial attempts, and workflow validations. This guide shows how to document application-level tests automatically, reducing manual work from 45 minutes to 3 minutes per control. ### Can AI Capture Screenshots and Generate SOC 2 Audit Reports? *Published: 2025-10-17 | Source: https://screenata.com/resources/blog/ai-screenshot-capture-soc2-audit-reports.md* Screenshot capture is one of several ways an AI compliance agent named Vera collects evidence. She captures application screenshots with DOM snapshots and signed timestamps, generates the control narrative, and maps each one to a Trust Services Criterion. Every artifact traces back to a control. This guide covers how it works and what auditors require to accept it. ### How AI-Generated Evidence Will Shape Auditor Workflows *Published: 2025-10-15 | Source: https://screenata.com/resources/blog/how-ai-generated-evidence-shapes-auditor-workflows.md* AI-generated compliance evidence moves auditor time away from chasing and re-checking screenshots and toward testing and judgment. It does not shorten the observation window, shrink the auditor's samples, or make the audit fee the saving. The saving is on your side: fewer clarification cycles and fewer team hours. ### Can Drata or Vanta Capture Screenshots for SOC 2 Evidence? *Published: 2025-10-03 | Source: https://screenata.com/resources/blog/drata-vanta-screenshot-evidence-manual-gap.md* Partly. Vanta added computer-use screenshot capture in August 2026; Drata has not announced an equivalent. Both automate infrastructure evidence via APIs, and neither reaches your authenticated application UI, workflow documentation, or attestations, because a cloud browser does not carry your session. This article explains what evidence stays manual, why a dashboard can't reach it, and how Vera, an agent that runs continuous compliance, does that work: capturing application evidence, chasing sign-offs, and filing signed, traceable packs. ### How to Automatically Convert Application Testing Into SOC 2 Evidence *Published: 2025-09-29 | Source: https://screenata.com/resources/blog/system-records-testing-creates-soc2-evidence.md* Yes, browser extensions automatically record application testing and convert it into SOC 2 evidence. This guide shows how testing-to-documentation systems capture screenshots, generate control descriptions, and create audit-ready PDFs, eliminating manual documentation and reducing audit prep from 80 hours to under 5 hours. ### Why Screenshots and Workflow Recordings Are Essential for Control Validation *Published: 2025-09-22 | Source: https://screenata.com/resources/blog/why-screenshots-essential-control-validation.md* Auditors require visual proof for roughly 25 to 35% of SOC 2 controls that logs and APIs cannot verify: access controls, UI security, and approval workflows. This guide covers which controls need it, what makes a screenshot auditor-ready, and how an AI compliance agent named Vera captures that proof as one signed input inside a broader evidence program. ### What Types of Evidence Can Be Automated Across SOC 2, ISO 27001, HIPAA, and CMMC? *Published: 2025-09-21 | Source: https://screenata.com/resources/blog/evidence-automation-across-frameworks.md* Screenshot-based access controls, workflow documentation, application testing, and UI validations can be automated across all major frameworks, covering 20-30% of evidence that traditional GRC tools cannot capture. ### How to Automate SOC 2 CC6.1 Evidence Collection for RBAC Testing *Published: 2025-09-05 | Source: https://screenata.com/resources/blog/prove-rbac-cc6-1-automated-evidence.md* Automate SOC 2 CC6.1 (logical access) evidence by capturing user permission matrices, role-based login tests, access denial screenshots, and audit logs. This guide shows how to document RBAC effectiveness with automated screenshot collection, reducing manual testing from 60 minutes to 5 minutes per quarter. ### What Tools Automate SOC 2 Screenshot Collection? Comparison Guide *Published: 2025-09-05 | Source: https://screenata.com/resources/blog/tools-replace-manual-screenshot-collection.md* Browser-extension AI agents, RPA platforms, screen recorders, and testing frameworks all capture screenshots, but only some produce audit-ready evidence. This guide compares the categories and shows where screenshot capture fits: it is roughly 9% of the evidence job, and the real question is whether a tool captures pixels or runs the whole program the way an agent named Vera does. ### What's the Best Way to Generate SOC 2 Control Evidence Automatically from App Workflows? *Published: 2025-08-17 | Source: https://screenata.com/resources/blog/generate-soc2-evidence-app-workflows.md* Multi-step workflows like change management, provisioning, and incident response are where SOC 2 evidence gets manual, because API records prove the outcome but not the path. Vera, the compliance agent behind Screenata, captures the workflow as it runs, drafts the step narrative, maps each artifact to a control, and files a signed pack. This guide covers the setup, five worked control examples, and what auditors check. ### How to Integrate Screenshot Automation with Drata or Vanta for SOC 2 *Published: 2025-08-15 | Source: https://screenata.com/resources/blog/integrate-screenshot-automation-drata-vanta.md* For teams evaluating Drata or Vanta, screenshot automation matters most when it is part of Vera's full evidence workflow. Vera owns API scans, UI captures, attestations, signed proof, and control mapping; export to Drata or Vanta is available when an existing audit workspace still needs the pack. ### How to Generate SOC 2 PDF Evidence Packs Automatically from Screenshots *Published: 2025-07-18 | Source: https://screenata.com/resources/blog/create-pdf-evidence-pack-automatically.md* A SOC 2 PDF evidence pack bundles the screenshots, the control narrative, the timestamps, and the signatures an auditor needs to accept a control test. Vera, the compliance agent behind Screenata, captures the screens, writes the step narrative, maps each artifact to a control, and assembles a signed pack you review before it is filed. This guide covers what belongs in a pack, how the automated build works, and what auditors check. ### What Drata Can (and Can't) Automate for SOC 2 Evidence *Published: 2025-06-25 | Source: https://screenata.com/resources/blog/automate-soc2-evidence-collection-screenshots.md* Can Drata fully automate SOC 2? See what Drata automates via API, the 20% manual evidence gap (UI screenshots, RBAC, access reviews), and how to close it. ### What is Compliance Evidence Automation and How Does It Work? *Published: 2025-06-20 | Source: https://screenata.com/resources/blog/compliance-evidence-automation-how-it-works.md* Compliance evidence automation is an agent that collects, documents, and signs audit evidence across every source. Screenata's agent Vera runs the control test, captures the application screenshots a dashboard can't reach, scores them against the control, chases attestations in Slack, and files signed, traceable packs, turning a 60-minute manual process into a few minutes of review. ### How to Automate SOC 2 Compliance Testing with AI Agents in 2026 *Published: 2024-01-15 | Source: https://screenata.com/resources/blog/future-ai-driven-compliance-workflow-recording-self-auditing.md* AI agents can automate 80% of SOC 2 compliance testing, evidence collection, and control monitoring autonomously. This reduces manual audit preparation from 200+ hours to roughly 60-80 hours in year one while improving accuracy from 85% to 99%+. This article explains how autonomous SOC 2 testing works, what controls can be automated, and how to implement AI-powered evidence collection for SOC 2, ISO 27001, and HIPAA audits.