Loading…
Loading…
Scorifya Controls · Help
Common questions compliance teams ask before and during a SOC 2 engagement — what tools miss, how auditors respond, what actually fails in practice, and exactly what Scorifya Controls delivers.
Nothing here is made up. Every Controls capability described below is in the shipped product.
The most common first question.
Probably not yet — until a prospect or customer asks for it. The moment an enterprise buyer or a security questionnaire requests your SOC 2 report, the answer becomes yes, and the typical preparation window is 6–12 months for a Type II. Starting your observation period before the demand arrives means you won't have to delay a deal while you scramble. Controls is built for exactly this stage: small team, no dedicated security staff, real compliance pressure on the horizon.
A Type I report says your controls are designed correctly at a single point in time. A Type II report says your controls operated effectively across an observation window — typically 6 or 12 months. Enterprise buyers almost always want Type II because it proves consistent operation, not just a snapshot. Controls helps you build and maintain the evidence trail Type II requires.
Automated checks surface your biggest gaps in the first run — usually within the first hour of setup. Most teams spend 2–4 weeks closing the critical and high-severity findings (MFA enforcement, CloudTrail, branch protection, encryption at rest). Manual controls take longer: security awareness training certificates, access review documentation, incident response plans. A realistic timeline is 3–6 months to have all controls in a defensible state before scheduling a Type II observation window.
It covers a meaningful subset of what those platforms do — automated cloud checks, manual control tracking, evidence collection, and an auditor-facing portal — at a fraction of the price. It does not replace them entirely. Vanta and Drata have broader integrations (HR systems, MDM, endpoint agents, more cloud services) and some auditors prefer their purpose-built auditor portals. Controls is sized for teams where $10,000–$15,000/year is not justifiable at their current stage.
A common challenge with self-hosted compliance tools.
This is the right question for an auditor to ask, and Controls answers it directly. Every manual control attestation is stamped with an RFC 3161 cryptographic timestamp issued by DigiCert — the same timestamp authority used for code-signed software and notarized legal documents. DigiCert signs a SHA-256 fingerprint of the attestation with the current time. The resulting token is stored in the database and available for download as a .tsr file. Your auditor can verify it independently using OpenSSL — no trust in Scorifya required. Controls even pre-fills the OpenSSL command in the auditor portal with the exact hash and CA certificate URL for each attestation.
Go to Settings → Audit Access, enter a label (e.g. 'PwC 2026 Type II'), choose an expiry (30, 60, 90, or 180 days), and generate a link. Send that URL to your auditor. They see all automated check results, all manual controls with status and evidence files, and per-attestation timestamp verification — no account, no install, no PDF. The link expires automatically and can be revoked any time from Settings.
Every check run is stored with its full result set and timestamp. The auditor portal and the print-to-PDF report both show run history grouped by date. For manual controls, the attestation history is preserved with each entry timestamped by DigiCert. The dashboard posture trend chart covers the last 30 runs, which your auditor can use to confirm controls operated across the observation window.
PDF, PNG, JPG, DOCX, XLSX, and CSV — up to 10 MB per file. Evidence files are stored on your own server, not on Scorifya's infrastructure. Auditors can download them directly from the auditor portal using the time-bounded link you generate.
This is a real concern and the reason the RFC 3161 timestamp feature exists. The timestamp token comes from DigiCert, an independent trusted third party. It cryptographically proves that an attestation existed at a specific time and has not been modified. The auditor verifies this token against DigiCert's certificate authority — independently, using OpenSSL — without relying on Scorifya or your database at all. The database stores the evidence; DigiCert proves when it was recorded.
The AWS SecurityAudit managed policy covers all 14 checks. It is read-only — no resources are created, modified, or deleted. Attach it to an IAM user or role dedicated to Scorifya. Your AWS credentials are stored in your own database and never leave your infrastructure.
Today, checks report pass or fail based on what they observe in your cloud account. There is no in-app way to mark a failing check as 'accepted risk.' If you have a compensating control, document it in the corresponding manual control's notes field, upload the supporting evidence, and include an explanation in the audit notes you give your CPA. Most auditors accept well-documented compensating controls.
Risk acceptance / exception flagging is on the roadmap.
On demand from the dashboard, or on a schedule via a cron job. You configure the schedule by calling POST /api/cron/run from any cron service (system cron, GitHub Actions, an external scheduler). If you set CRON_SECRET, that request must include x-cron-secret: <value> in the header. Most teams run checks daily or twice daily.
Rarely for the checks Controls runs, because they query resource configuration rather than real-time state. However, newly created resources (a new IAM user, a new S3 bucket) may not show the expected configuration for a few minutes. Re-running the checks after a few minutes will reflect the settled state.
Controls connects to one set of AWS credentials per instance. If you run workloads across multiple AWS accounts, you can connect the account where your most sensitive workloads live, or set up a cross-account IAM role that grants the SecurityAudit policy across your organization. The checks run against whichever account the credentials belong to.
Yes. Each cloud provider is connected independently. You can connect any combination — GitHub only, GCP only, Azure + GitHub — and the checks run only for the providers you've configured. The 33-check total reflects all four providers; your posture score reflects only the checks you've enabled.
20 controls across 9 categories: Governance (security policy approval, management oversight), HR & Training (annual security awareness training, background checks, NDAs), Access Management (quarterly access reviews, offboarding within 24 hours, privileged access review), Risk Management (annual risk and fraud risk assessments), Change Management (change approval process, security in SDLC), Incident Response (IR plan, annual tabletop exercise, breach notification), Business Continuity (BCP documentation, annual DR test), Vendor Management (annual vendor review, DPAs/BAAs in place), and Monitoring (annual penetration test).
Training completion certificates from your LMS (PDF or screenshot), or a CSV export showing completion dates per employee. Many teams also upload the training slide deck or course outline. The evidence URL field works well if your LMS hosts completion records online — paste the link directly. Add a note in the notes field explaining the training provider, date, and how many staff completed it.
A documented list of who reviewed access, which systems were reviewed, what was found, and what was changed. This can be as simple as a PDF or spreadsheet exported from your identity provider or ticketing system — showing reviewer name, date, accounts reviewed, and any access removed. The control is satisfied when there's a timestamped artifact showing someone looked at access and made a deliberate decision.
The control row turns red in the dashboard and the manual controls panel shows an overdue count at the top. No automated action is taken — no notifications are sent when a review date passes. Use Slack drift alerts for automated check failures; for manual controls, the dashboard overdue indicator is the signal. Your auditor will look at these dates, so addressing overdue items before the audit report period is important.
Yes. You can invite team members from Settings → Team. Each invited user can log in and update any manual control attestation, including uploading their own evidence files. The owner field on each control records who is accountable, and each attestation records when it was last updated.
On your infrastructure, in a SQLite database on a persistent Docker volume (or a Turso libsql database if you prefer managed SQLite). Evidence files are stored on the same server in an evidence/ directory. AWS credentials, GitHub tokens, GCP service account JSON, check results, attestation records, and uploaded files never leave your environment. There is no telemetry.
License validation — a daily POST to licenses.scorifya.com with your license key and domain. Nothing else. No check results, no attestation data, no credentials, no usage telemetry. A 48-hour grace period applies if the license server is temporarily unreachable.
Yes. Set TSA_URL to your internal RFC 3161 timestamp server, TSA_NAME to a display label (e.g. 'Internal CA'), and TSA_CA_CERT_URL to the URL of your CA certificate. Set TSA_ONLY=1 to skip DigiCert and Sectigo entirely. Any RFC 3161-compliant TSA works — Microsoft Active Directory Certificate Services with the Online Responder role, EJBCA, or OpenSSL's ts server. The .tsr output format is standard regardless of which TSA issued it.
For the workload Controls runs — one instance, tens of users, daily check runs, evidence file references — SQLite is appropriate. It has no network latency, requires no separate database server, and handles concurrent reads well. Writes are serialized, which is fine for this access pattern. If you prefer managed infrastructure with automated backups, Turso (libsql) is supported via the DATABASE_URL and TURSO_AUTH_TOKEN environment variables.
For SQLite: mount the database volume to a host path and back up the .db file with any standard backup tool (rsync, S3 sync, Restic). SQLite databases are single-file and safe to copy while Controls is running as long as you use SQLite's backup API or copy when the file is idle. For Turso: use Turso's built-in point-in-time recovery.
Yes. Each instance is an independent Docker container with its own database and license key. Each license covers one instance. If you need separate isolation per team (different AWS accounts, different audit periods), run separate instances each with their own license.
One of the most common first-run findings.
This is the most frequently missed check in early-stage AWS accounts. The root account is often set up once and never touched again, and MFA is not enforced by default. Enable a virtual MFA device (or hardware key) on the root account immediately — this is a Critical finding that auditors will flag. After enabling it, Controls will report this check as passing on the next run.
CloudTrail needs a multi-region trail to pass. A single-region trail leaves activity in other regions unlogged. In the AWS console, go to CloudTrail → Trails → Edit your trail → enable 'Apply trail to all regions.' Alternatively, create a new multi-region trail. The check passes as soon as at least one multi-region trail is active.
The S3 public access block check looks at the account-level block, not per-bucket settings. If your product legitimately needs public buckets (static assets, public downloads), you can enable public access at the individual bucket level while keeping the account-level block enabled — that configuration passes the check. Document the business justification for each intentionally public bucket in your audit notes.
The check looks at whether 2FA is required at the organization level — not just whether individual members happen to have it enabled. Go to GitHub org Settings → Authentication security → enable 'Require two-factor authentication for everyone in your organization.' GitHub will remove members who don't comply within 3 days, so warn your team first.
Run an IAM credential report in the AWS console to see all users and their last-used dates. Deactivate or delete credentials that are no longer needed. If a service integration stopped using credentials but still holds active keys, rotate or disable them. After cleanup, the next check run will show compliant if all remaining credentials have been used within 90 days.
This is one of the 20 manual controls (Monitoring category). Upload your most recent pentest report as evidence with the testing firm's name, scope, and date. If the test is overdue, attest the control as 'In Progress', document that a new test is scheduled (with the date), and note any remediated findings from the previous report. Auditors want to see a pattern of testing — a gap in cadence is less damaging when you can show the remediation history from prior tests.
One license key per running instance. Unlimited users per instance, unlimited check runs, all 33 automated checks, all 20 manual controls, evidence file uploads, cryptographic timestamps, and the auditor portal. Annual flat fee — no per-seat charges, no per-check charges, no add-on pricing for additional cloud providers.
The dashboard becomes read-only. Existing data — check results, attestations, evidence files — remains accessible. Write operations (updating attestations, running checks, generating auditor links) are paused until the license is renewed. You will not lose your data.
Use the self-service license recovery page — enter your purchase email and the key is resent immediately. No support ticket needed.
No. Use the domain change page — enter your email, license key, and new hostname. The change takes effect on the next daily validation. No restart required.
The Docker image is publicly available. You can run Controls locally with no license key — the dashboard is read-only but all screens, check tables, and manual control layouts are visible so you can evaluate the product before purchasing.
Reach out directly — no sales process, no demo required.