{
  "name": "Sock Too",
  "version": "1.0",
  "license": "CC-BY-4.0",
  "attribution": "Sock Too project",
  "applicability": "A baseline for small organizations operating ordinary business systems. Assessments cover the whole organization, including its people, systems, services, and data. This standard does not establish legal compliance or suitability for regulated or high-risk processing.",
  "passing": "Complete all six knowledge checks, answer all 18 controls, implement all six essential controls, and achieve an unrounded control average of at least 80 out of 100. Implemented = 100, In progress = 50, Not yet = 0. Every control is equally weighted. No answer is excluded from scoring.",
  "validity_days": 365,
  "renewal": "A new attestation requires reviewing all six lessons and passing their knowledge checks again, then reconfirming all 18 controls. Existing certificates never change their original answers. Revoke a record promptly if a material change makes its declarations inaccurate.",
  "evidence": "Evidence suggestions are for the organization's own records; Sock Too does not collect or verify evidence in this version. An Implemented answer means every condition in the control is currently met across the organization. Partial coverage or an untested plan is In progress. Plans without implementation are Not yet. Do not put credentials, vulnerabilities, personal data, or confidential documents into public organization details or revocation reasons.",
  "sources": [
    {"title":"NIST CSF 2.0 Small Business Quick-Start Guide — further reading", "url":"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1300.pdf"},
    {"title":"NIST Privacy Framework — further reading", "url":"https://www.nist.gov/privacy-framework"},
    {"title":"U.S. Small Business Administration cybersecurity resources — further reading", "url":"https://www.sba.gov/business-guide/manage-your-business/strengthen-your-cybersecurity"}
  ],
  "independence": "Sock Too is an independently authored standard. These references are further reading, not a claim of endorsement, formal mapping, or equivalence to another framework.",
  "modules": [
    {
      "id":"access", "title":"Access & identity", "subtitle":"Give the right people the right keys.",
      "text":"List the accounts that control your hosting, domain, email, code, backups, and customer data. Protect these first: access to one can often be used to take over others.",
      "lessons":[
        {"title":"Protect the keys to the business", "body":"Require multi-factor authentication for every human account with administrative access. Prefer passkeys or security keys when supported, and keep recovery codes somewhere protected and available to the owner. Keep recovery codes outside the account they recover. If an administrative service cannot support MFA, move it behind an enforced MFA access gateway or replace it before claiming the essential control is implemented. Machine service credentials are handled by the secrets control below."},
        {"title":"Make access individual and intentional", "body":"Use a named account for each person rather than one shared administrator login. Give people the smallest role that supports their work, and use separate privileged access where the service supports it. Write down who can approve access, how departures are handled, and when you last reviewed the list. Sock Too asks for a review at least every 90 days and removal by the end of someone's final working day, or immediately when access is withdrawn."},
        {"title":"Keep secrets out of everyday work", "body":"Store unique passwords in a password manager and application secrets in a protected configuration or secret store. Keep API keys and credentials out of source code, tickets, public documents, and logs. Restrict service accounts to their intended job. If a secret is exposed, revoke or rotate it; deleting it from the latest file does not remove copies or history. Record the action without recording the secret itself."}
      ],
      "practices":["List administrators and protect their sign-ins with MFA.","Review access every 90 days and remove it promptly when people leave.","Use protected secret storage and rotate credentials after exposure."],
      "quiz":{"question":"A contractor has finished their work. What is the best next step?", "options":["Leave their access active in case they return.","Remove their access, review shared secrets they knew, and record the change.","Rename their account and give it to the next contractor."],"correct":1,"explanation":"Access should follow current responsibilities. Remove individual access promptly and rotate shared credentials where needed; changing a name does not remove the former person's access."},
      "controls":[
        {"id":"access_mfa","title":"Privileged MFA","question":"Is MFA enforced for all human administrative access across the organization?","guidance":"Cover hosting, domains, email administration, source code, backups, and other administrative services. A service without native MFA must sit behind an enforced MFA gateway. Shared recovery codes must be protected. Service accounts are addressed under secret management.","evidence":"A dated list of administrative services and their MFA enforcement settings, with no secrets included.","essential":true,"action":"List administrative entry points and enforce MFA on each, including recovery access."},
        {"id":"access_review","title":"Account lifecycle","question":"Are human accounts individual, access limited by role, and access reviews performed at least every 90 days?","guidance":"Also remove access by the end of the final working day or immediately when authorization is withdrawn. An owner-only organization can meet this by reviewing its own accounts and documenting the result.","evidence":"An access list, latest review date, and a short joiner/leaver checklist.","essential":false,"action":"Assign named accounts, remove unnecessary privileges, and record a dated access review."},
        {"id":"access_secrets","title":"Secret management","question":"Are passwords unique, secrets stored in protected tools or configuration, and exposed credentials promptly revoked or rotated?","guidance":"Use a password manager for human credentials. Protect application secrets and narrowly scope service accounts. Credentials must not be stored in source repositories, public documents, or ordinary logs.","evidence":"Your secret-handling procedure and a record of any credential rotations, without the credentials themselves.","essential":false,"action":"Move credentials into protected storage and document how exposure triggers revocation or rotation."}
      ]
    },
    {
      "id":"systems","title":"Systems & updates","subtitle":"A little maintenance goes a long way.",
      "text":"Keep a list of your devices, applications, and hosted services. Record an owner, purpose, and any sensitive data for each. Use it to track updates and check what is exposed.",
      "lessons":[
        {"title":"Keep the foundation supported", "body":"Unsupported software stops receiving fixes. Use supported systems, enable automatic updates where appropriate, and assign someone to review important security advisories. Sock Too's essential requirement is to assess a known critical or actively exploited issue affecting an internet-facing system within 72 hours of learning of it, then patch or isolate the affected component within seven days. Take immediate action when active compromise is suspected; seven days is an outside limit, not permission to wait. Other security updates should be applied within 30 days or have a documented risk decision and mitigation."},
        {"title":"Know what is exposed", "body":"Review your inventory at least every 90 days and when you add or remove a service. Use disk encryption on work devices that store organization data, automatic screen locking, supported anti-malware or built-in platform protections, and a firewall where applicable. Administrative interfaces should be restricted to authorized users and appropriate networks. A service that must be public still needs secure configuration and authentication for privileged actions."},
        {"title":"Change carefully", "body":"Before significant changes, identify who is responsible, how the change will be checked, and how to recover if it fails. Keep a simple record of production changes. For a tiny team this can be a ticket, deployment log, or checklist; it does not require a committee. Test changes on nonproduction data when practical, and avoid copying customer secrets into a test environment."}
      ],
      "practices":["Track supported systems and assign an owner to security updates.","Review exposed services and protect work devices.","Check important changes and keep a recovery path."],
      "quiz":{"question":"You learn of an actively exploited flaw in a public-facing service you operate. What should happen?","options":["Assess it promptly, patch or isolate it within the defined window, and check for signs of compromise.","Wait for the next annual review.","Assume a firewall means the software never needs updating."],"correct":0,"explanation":"Prioritize exposure and exploitability. A known exploited flaw needs prompt assessment, remediation or isolation, and investigation if compromise is suspected."},
      "controls":[
        {"id":"systems_updates","title":"Supported and patched systems","question":"Are the organization’s systems supported, with a process meeting Sock Too's critical and routine security-update timelines?","guidance":"Assess known critical or actively exploited issues affecting internet-facing systems within 72 hours of awareness; patch or isolate within seven days. Apply other security updates within 30 days, or record a risk decision and mitigation. Suspected active compromise triggers immediate incident response.","evidence":"System support status, update settings, recent patch records, and any documented exceptions for routine updates.","essential":true,"action":"Remove or isolate unsupported systems and assign an owner to the critical and routine patch process."},
        {"id":"systems_inventory","title":"Inventory and device protection","question":"Do you maintain a current asset inventory and protect work devices with encryption, screen locks, and appropriate platform protections?","guidance":"Include hosted services and devices holding organization data. Review the inventory at least every 90 days and on material changes. Restrict administrative exposure and remove unneeded services.","evidence":"An asset inventory, its last review date, and a device/security configuration checklist.","essential":false,"action":"Create an inventory, assign owners, and check encryption, locking, and exposed administration."},
        {"id":"systems_changes","title":"Controlled changes","question":"Do significant production changes have an owner, a check or test, a recovery plan, and a change record?","guidance":"A short checklist or deployment record is sufficient. Test with nonproduction data where practical, and know how to roll back or restore before making the change.","evidence":"A recent change ticket or deployment record showing validation and rollback or recovery steps.","essential":false,"action":"Add validation and recovery steps to your production change checklist."}
      ]
    },
    {
      "id":"backups","title":"Backups & recovery","subtitle":"Have a way to get back on your feet.",
      "text":"Back up the data and configuration you need to recover. Keep copies separate from the live system, then test that you can restore them.",
      "lessons":[
        {"title":"Keep a recoverable copy", "body":"Maintain a copy of critical data and configuration separate from the primary system, with access restricted so that a compromised everyday account cannot freely destroy every copy. Provider redundancy is not automatically a backup: it may replicate accidental deletion or corruption. For a stateless service, the recoverable material may be code, infrastructure configuration, and deployment instructions. Document that choice rather than treating recovery as not applicable."},
        {"title":"Test the part that matters", "body":"A successful backup job does not prove you can restore. Sock Too requires a documented recovery test within the last 180 days, including a representative restore or rebuild and a check that the result works. A new organization can run its first test before attesting. Record what was tested, the result, any missing steps, and who owns fixes. Use a safe test environment and avoid exposing sensitive backup data."},
        {"title":"Match the plan to the business", "body":"Set backup frequency and retention based on how much data loss you can tolerate. Assign someone to review failed jobs and capacity alerts. Keep recovery instructions and access methods available if the main service is down. Protect backup data in transit and at rest, and define how old copies expire; keeping every copy forever can undermine your privacy and deletion practices."}
      ],
      "practices":["Keep critical data or rebuild materials separate from the primary system.","Perform and record a recovery test at least every 180 days.","Monitor backups and document your recovery targets and retention."],
      "quiz":{"question":"Your backup dashboard shows successful jobs. What gives you confidence the business can recover?","options":["Keeping the dashboard screenshot alone.","Using the same administrator credentials for every backup location.","Restoring or rebuilding a representative system and checking that it works."],"correct":2,"explanation":"A recovery test exercises data, permissions, instructions, and dependencies. A successful backup job alone does not establish recoverability."},
      "controls":[
        {"id":"backups_restore","title":"Separate copies and tested recovery","question":"Do you keep separate recoverable copies of critical data/configuration and have a successful recovery test from the last 180 days?","guidance":"Restrict access so ordinary account compromise cannot freely destroy all copies. A stateless service may use a tested rebuild from separately stored code and configuration. Record the test date and outcome; an untested plan is In progress.","evidence":"Backup or rebuild coverage plus a dated, successful restore/rebuild test record.","essential":true,"action":"Make a separate recoverable copy and complete a documented restore or rebuild test."},
        {"id":"backups_monitor","title":"Backup monitoring","question":"Are backup or rebuild-material checks scheduled, failures reviewed, and recovery targets documented?","guidance":"Set acceptable data loss and downtime targets. Make frequency and retention consistent with those targets, and assign an owner to investigate failures.","evidence":"Recovery targets, backup schedule, and a recent check or failure-resolution record.","essential":false,"action":"Write recovery targets and assign someone to check backup failures and coverage."},
        {"id":"backups_protection","title":"Protected recovery materials","question":"Are recovery materials protected in transit and at rest, retained for a defined period, and accompanied by accessible recovery instructions?","guidance":"Limit permissions, protect recovery keys, and ensure the instructions can be reached during an outage. Define expiration for old backup copies and account for it in your retention practice.","evidence":"Backup permissions and retention settings, plus an accessible recovery runbook without public secrets.","essential":false,"action":"Protect backup access and document retention, recovery keys, and outage-safe instructions."}
      ]
    },
    {
      "id":"privacy","title":"Data & privacy","subtitle":"Take care of what people entrust to you.",
      "text":"Know what personal and confidential data you hold, why you need it, who can access it, and when it should be deleted.",
      "lessons":[
        {"title":"Know what you hold and why", "body":"List the categories of personal or confidential data you handle, the purpose of each, where it lives, who can access it, and how long you keep it. Include logs, exports, vendors, and backups. If you collect no personal data in a particular service, record that and check supporting systems such as analytics and support before concluding there is none. Sock Too requires this inventory and a defined retention/deletion practice as an essential control."},
        {"title":"Reduce and protect", "body":"Avoid collecting fields you do not need. Limit access to people with a business purpose, use secure transport for network transfers, and protect confidential data in storage. Keep secrets and personal information out of logs where they are not needed. Deleting from an active database may not instantly erase protected backups; document their expiry and avoid restoring deleted data into active use without reapplying deletion rules."},
        {"title":"Explain and respond", "body":"Give people an accurate description of the data practices relevant to them and a way to reach the responsible person. Assign someone to review requests for access, correction, or deletion and to identify applicable obligations. Requirements vary with your location, customers, contracts, and data; completing this course does not settle those questions. When publishing a Sock Too report, do not include personal records, credentials, or exploitable system details."}
      ],
      "practices":["Inventory data, purpose, storage locations, and retention.","Collect less, restrict access, and protect transfers and storage.","Provide accurate explanations and a contact for privacy requests."],
      "quiz":{"question":"A customer asks for deletion, but protected backups retain old copies for 30 days. What is the sound approach?","options":["Promise that every copy disappears immediately, whether or not that is true.","Follow the applicable request process, explain actual retention, and prevent deleted data from returning to active use.","Ignore the request because backups exist."],"correct":1,"explanation":"Your explanations should match actual handling. Apply the relevant request process, account for backup expiry, and reapply deletion rules during recovery."},
      "controls":[
        {"id":"privacy_inventory","title":"Data inventory and retention","question":"Have you documented the data you handle, its purposes and locations, and an implemented retention/deletion practice?","guidance":"Include personal and confidential data in applications, logs, exports, vendors, and backups. Record justified cases of no collection. A retention policy with no implementation is In progress.","evidence":"A data inventory and retention schedule, plus a recent deletion or retention check.","essential":true,"action":"Map your data and implement a retention/deletion routine that matches the documented schedule."},
        {"id":"privacy_protection","title":"Data minimization and protection","question":"Do you minimize data collection, restrict data access by role, and protect sensitive transfers and storage?","guidance":"Use secure network transport and appropriate storage protection. Avoid unnecessary personal data or secrets in logs and test environments. Cover the whole organization.","evidence":"Data-access settings, transport/storage configuration, and a check of collection and logging practices.","essential":false,"action":"Remove unnecessary fields and logging, and check access, transport, and storage protection."},
        {"id":"privacy_requests","title":"Privacy communication and requests","question":"Do you accurately explain your data practices and have an owner and process for privacy requests and applicable obligations?","guidance":"Provide an accessible contact or request channel. The owner must identify relevant contractual and legal requirements rather than treating Sock Too as a substitute for them.","evidence":"Your privacy explanation, request contact, and an internal request-handling checklist.","essential":false,"action":"Publish an accurate data-practices explanation and assign a privacy-request owner and process."}
      ]
    },
    {
      "id":"response","title":"Incident readiness","subtitle":"Make a plan before you need one.",
      "text":"Choose who handles security incidents and how to reach them. Write down the response steps and keep the plan somewhere you can access during an outage.",
      "lessons":[
        {"title":"Assign an owner and a route for reports", "body":"Name the person who coordinates a suspected incident, their backup or escalation contact, and how staff or customers report concerns. For a solo operator, an appropriate external support or service contact can be the escalation route. Keep the plan accessible outside the affected service. Sock Too's essential control includes written steps to assess the report, contain the problem, recover safely, and decide who needs communication."},
        {"title":"Notice trouble and preserve context", "body":"Enable relevant security logs and available alerts for critical systems, including privileged changes and unusual sign-ins where the service supports them. Assign an owner to respond to alerts and review relevant activity at least weekly. Protect logs against unauthorized access or alteration and retain relevant security events for at least 30 days unless an identified obligation requires different handling. Do not add secrets or unnecessary personal information just to make logs more detailed."},
        {"title":"Practice, then improve", "body":"Walk through a realistic scenario at least once a year: a lost laptop, stolen cloud administrator account, or exposed customer file. Ask how you would notice, contain, investigate, recover, and communicate. Preserve useful evidence while limiting harm; indiscriminate deletion can make investigation harder. Identify notification decisions from applicable contracts and requirements rather than inventing a deadline. Record lessons and owners for improvements. A new organization can run its first exercise before attesting."}
      ],
      "practices":["Name an incident owner and document reporting, containment, recovery, and communication.","Enable useful logs and alerts, with someone responsible for reviewing them.","Practice a scenario at least annually and follow up on lessons."],
      "quiz":{"question":"You suspect an administrator account has been compromised. Which response is best?","options":["Alert the incident owner, contain access, preserve useful evidence, and follow the recovery and communication plan.","Delete all logs immediately to clean up the system.","Wait until you can prove every detail before taking any action."],"correct":0,"explanation":"Prompt coordination and proportionate containment limit harm. Preserve context for investigation and use the response plan to guide recovery and communication."},
      "controls":[
        {"id":"response_plan","title":"Owned incident response","question":"Do you have an accessible incident plan with a named owner, reporting/escalation contacts, and containment, recovery, and communication steps?","guidance":"Include a backup or external escalation contact and a way to reach the plan during an outage. The plan must identify who evaluates notification obligations.","evidence":"A current response plan and contact list stored somewhere reachable during an incident.","essential":true,"action":"Write a short incident plan, name an owner and escalation contact, and make it accessible during outages."},
        {"id":"response_detection","title":"Logs and alert handling","question":"Are relevant security logs and available alerts enabled, protected, and reviewed by an owner at least weekly?","guidance":"Respond to urgent alerts promptly. Retain relevant security events for at least 30 days unless an identified obligation requires different handling. Include privileged activity and unusual sign-ins where supported.","evidence":"Logging/alert configuration, retention settings, and a recent activity review.","essential":false,"action":"Enable useful security events and alerts, set retention, and assign a review and response owner."},
        {"id":"response_exercise","title":"Practiced response","question":"Have you practiced an incident scenario within the last year and assigned follow-up actions from the exercise?","guidance":"A documented tabletop conversation is enough; do not create a real incident. A solo operator can walk through the plan with their escalation contact or record a structured self-exercise.","evidence":"A dated scenario, decisions made, gaps identified, and owners for follow-up actions.","essential":false,"action":"Run a short incident walkthrough and record improvements, owners, and due dates."}
      ]
    },
    {
      "id":"people","title":"People & partners","subtitle":"Security is a team sport.",
      "text":"Assign a security owner and document the practices your team follows. Keep track of risks, vendor access, and the commitments you have made to customers.",
      "lessons":[
        {"title":"Own the baseline", "body":"Name a security owner, define the systems and people covered, and document the practices you expect. Record material risks, decisions, and an owner for improvements. Review the baseline at least annually and when the business changes materially. Sock Too treats ownership and this review practice as essential. An owner can also be the founder; the role does not require a separate hire."},
        {"title":"Give people usable guidance", "body":"Anyone with access to organization systems should know how to protect credentials, recognize suspicious requests, report an incident, and handle personal or confidential information. Cover these topics before granting access and refresh them at least annually. Show people a reporting route they can actually use. A solo operator can satisfy training with their own recorded completion of this course and a review of their local procedures."},
        {"title":"Check the partners and promises", "body":"List providers that access organization systems or hold relevant data. Before using them, consider their security information, data handling, access, availability, and exit options; review the relationship at least annually. If your organization uses none, record that finding rather than skipping the inventory. Keep a short list of relevant customer commitments and other obligations, and assign someone to review changes. Your answers must reflect practices across the whole organization."}
      ],
      "practices":["Assign a security owner and review the baseline and material risks.","Train everyone with access, including the owner, on practical responsibilities.","Review providers and track the obligations you have agreed to meet."],
      "quiz":{"question":"A small company has no dedicated security employee. Who can own its security baseline?","options":["Nobody; ownership is only needed once the company is large.","The software vendor automatically owns every responsibility.","A named founder or team member who maintains the security baseline, reviews risks, and follows up on actions."],"correct":2,"explanation":"Accountability can be lightweight. A named owner with a practical review process is more useful than assuming responsibility sits with nobody or entirely with a vendor."},
      "controls":[
        {"id":"people_owner","title":"Security ownership and review","question":"Is a security owner assigned, with documented baseline practices, material risks, and an annual/material-change review process?","guidance":"The owner may be the founder. Record your initial review before attesting and identify owners for open improvements. A calendar reminder alone without an initial baseline is In progress.","evidence":"A named owner, organization-wide baseline, dated initial or annual review, and a short risk/action list.","essential":true,"action":"Name the owner, document the organization-wide baseline and material risks, and complete the initial review."},
        {"id":"people_training","title":"Practical security awareness","question":"Do all people with system access receive security and privacy guidance before access and refresh it at least annually?","guidance":"Include credential protection, suspicious requests, incident reporting, and data handling. An owner-only organization can use this course plus a review of its own procedures; record that completion before answering Implemented.","evidence":"Training topics, completion records, and the local reporting/data-handling instructions provided.","essential":false,"action":"Train everyone with access and record completion and the next refresh date."},
        {"id":"people_vendors","title":"Providers and obligations","question":"Do you inventory and review relevant providers and track the security/privacy obligations applicable to your organization?","guidance":"Review providers before use and at least annually, including access, data handling, security information, and exit options. If there are none, document the review and finding. Assign an owner to relevant contractual and other obligations.","evidence":"A provider list and review, relevant commitments, and their responsible owner.","essential":false,"action":"List relevant providers and obligations, review their risks, and assign follow-up owners."}
      ]
    }
  ]
}