SOC Binder
ProductWho it’s forPricingSecurityWhat it won’t do
Sign inRequest access

Privacy Policy

Effective October 19, 2026 · RuneSpoke Inc.

In short. We collect what we need to run your account and to collect SOC 2 evidence you ask us to collect. We do not sell personal information, show ads, use analytics or tracking, or train models on your data. For the evidence and records your organization puts into SOC Binder, your organization decides what happens to it and we act on its instructions.

1. Who we are

SOC Binder (socbinder.com) is operated by RuneSpoke Inc., a Delaware corporation (“RuneSpoke,” “we,” “us”). This policy explains what personal information we handle when you visit the website or use the service, why, and the choices you have. It should be read with our Terms of Service and Cookie Policy.

2. Our two roles

  • Account and website data — information about you as a user of SOC Binder, such as your email address and sign-in activity. We decide how this is used, so for this data we are the controller (GDPR) or business (CCPA).
  • Customer Data — what your organization puts into or collects with SOC Binder: cloud configuration evidence, the workforce roster, vendors, incidents, documents, uploaded files and the like. Your organization decides what goes in and why. For this data we are a processor or service provider acting on your organization’s instructions, and requests about it should normally go to your organization first. We will help it answer them.

3. What we collect

When you create and use an account

  • Your organization’s name, your email address, and your name if a teammate who invites you supplies it.
  • Your password, stored only as a one-way scrypt hash — we cannot read it. If you turn on two-factor authentication, its secret is stored encrypted, and recovery codes only as hashes.
  • Your role in the organization, and whether you have confirmed your email address.
  • If you sign in with Google, Microsoft or GitHub: your account identifier there, your name and your email address. We never see your password at that provider and ask for no other access.
  • If your organization signs in through its own identity provider (SAML single sign-on): the email address and name it sends when you sign in.
  • Your mobile number, if you add one. It is used only for what you turn on: codes to confirm it’s you at sign-in and on a password reset, and alerts you ask for. We never use it for marketing. Reply STOP to any text to opt out.
  • What you do in the product that the product itself records — for example who approved a document, assigned a control or answered an auditor’s request, which is part of the audit trail your organization relies on.

Security and technical records

  • A session record for each sign-in, holding a hash of the session token and when it was last used. Sessions end after 7 days, or after 12 hours without use, whichever comes first.
  • Records of sign-up, sign-in, password-reset and two-factor attempts, used to stop password guessing and abuse. These contain your IP address and, for some attempts, the email address or account tried. They are deleted after 48 hours.
  • If your organization uses API keys: a record of each call made with one — the method and address requested, the result, the time, which key made it, and the IP address it came from. Your organization’s owners and admins can see these records. They are deleted after 90 days.
  • Web server logs: your IP address, the page requested, the time, and your browser’s user-agent string. They are rotated by size and overwritten automatically.

Customer Data your organization provides or connects

  • Cloud configuration from AWS. Through a read-only IAM role your organization creates (AWS’s SecurityAudit policy), we read configuration such as IAM users and their MFA status, S3 bucket settings, security groups, encryption and logging settings. This can include IAM user names, which are often people’s names. We do not read the contents of S3 objects, databases or logs, and this role cannot change anything in your account.
  • Fixes you approve. If your organization chooses to deploy SOC Binder’s separate, optional fix role, we can apply the specific changes it lists — for example turning on encryption for a storage bucket — after they are approved. We record what was proposed, who approved it, what changed and the setting before and after, in a tamper-evident audit trail.
  • Repository settings from GitHub, if connected: repository names, branch protection, whether security scanning is configured, counts of open security alerts, and whether your GitHub organization requires two-factor authentication. We do not read source code, commits or pull requests.
  • Background-check results from Checkr, if connected: for each person on your organization’s workforce roster, and nobody else, whether a background check exists, whether it is finished or pending, the date it finished and the name of its package. We do not read or keep the report’s result (such as “clear” or “consider”), what it found, criminal or other records, adjudication decisions, dates of birth, Social Security numbers or addresses, and we never order checks.
  • Records your organization enters: the workforce roster (names, work emails, roles, start and end dates, and the dates of checks such as background checks and training), vendors, risks, assets, incidents, policies and documents, comments, and files uploaded as evidence.
  • Auditor access: the label your organization gives a share link, when it was used, and requests an auditor raises.
  • Vendor signatures. When your organization asks a vendor to sign a document, we record the signer’s name, title, email address, the time, their IP address and their browser’s user-agent string, and print them on the signed copy as evidence of who signed and when.
  • Trust Center requests. When somebody asks for documents on an organization’s public Trust Center, we record the name, work email address and company they give, the confidentiality agreement they accepted, the time and their IP address, and pass them to that organization to decide on. If it approves, we email them a link, and record each time it is opened and each document downloaded, with the IP address. Their email address is printed on every page of the documents they download. This is the organization’s Customer Data; ask it about it.

When your organization uses the SOC agent

The SOC agent is an optional AI feature, off unless enabled for your organization. When someone runs it, we send the summaries of your failing checks — which can include resource names such as bucket names and AWS user names — to Anthropic, whose AI model writes the explanation and suggests fixes. Anthropic processes this as our subprocessor, and under its commercial terms may not use it to train its models. If your organization adds its own Anthropic API key, the request is made through your organization’s own Anthropic account instead, under your agreement with Anthropic; we store that key encrypted and show only its last four characters. We keep the agent’s report and what each run cost.

The agent can also draft answers to a security questionnaire your organization uploads. For that, the questions, the state of your controls (without resource names) and the text of your approved policies are sent to Anthropic in the same way. Questions your organization has answered before are filled in from its own library of approved answers, and are not sent anywhere.

When you ask to join the private beta

Your work email address, name, company, its size, where your product runs, when you hope to be audited, your auditor if you have chosen one, and anything you tell us you need. We use it to decide who to invite and when, and to email you about it — an acknowledgement, and an invitation if there is room. Staff who decide record a short note about the decision.

When you contact us

The contents of emails you send us, and our replies.

What we do not collect

We use no analytics, advertising or tracking tools, and no third-party scripts or fonts. We do not buy personal information or collect it from data brokers. We do not currently take payments, so we hold no payment card details.

4. How we use it, and our legal bases

  • To provide the service you signed up for — your account, evidence collection, reports and notifications (performance of a contract).
  • To keep it secure — preventing account takeover, abuse and fraud, and investigating incidents (legitimate interests).
  • To email you about your account — address confirmation, password resets, invitations, alerts when a control you monitor gets worse, and a weekly summary. These are part of the service rather than marketing (contract; legitimate interests).
  • To answer you when you contact us (legitimate interests).
  • To meet legal obligations and enforce our Terms (legal obligation; legitimate interests).

We process Customer Data only to provide the service to your organization and as it instructs. We do not use Customer Data to train machine-learning models, and we do not send marketing email.

5. Who we share it with

  • Service providers who run parts of the service for us under contract, listed on our Subprocessors page. Principally Amazon Web Services, which hosts the service and delivers our email, and Anthropic, if your organization uses the SOC agent.
  • People your organization chooses — teammates it invites, and auditors it gives a share link to.
  • Authorities, when the law requires it. Where we lawfully can, we will tell your organization first.
  • A buyer or successor if RuneSpoke is involved in a merger, acquisition or sale of assets, under this policy’s protections.

We do not sell personal information, and we do not “share” it for cross-context behavioral advertising as the CCPA uses that word.

6. Where it is stored

The service runs in the United States, in AWS US East (Ohio), us-east-2. If you are in the European Economic Area, the United Kingdom or Switzerland, your information is transferred to the United States. Where the law requires a transfer mechanism, we rely on the European Commission’s Standard Contractual Clauses and the UK Addendum, which our Data Processing Addendum incorporates.

7. How long we keep it

  • Account and Customer Data: for as long as your organization’s account is open. Evidence history is kept for the life of the account because an audit’s observation period depends on it.
  • Removed evidence: when someone removes an evidence file in the product it is hidden and marked as removed, not erased, so the audit trail stays intact. It is erased with the rest of the account.
  • Closing an account: we delete the organization’s data from the live service within 30 days of a verified request.
  • Backups: encrypted nightly database backups expire after 35 days, so deleted data leaves the backups within that time.
  • Sessions: at most 7 days.
  • Sign-in links: password-reset links last 60 minutes; invitation links 7 days; email-confirmation links 7 days. Used and expired links are deleted 30 days after they expire.
  • Abuse-prevention records: 48 hours.
  • API call records: 90 days.
  • Text-message codes: they expire in 10 minutes and are deleted within a day. A log of texts sent — the last four digits of the number, the purpose and the time, never the content — is kept 90 days.
  • Private-beta requests: while the private beta runs, so we can tell you when there is room, and deleted sooner if you ask. An invitation link lasts 14 days.
  • Emails with us: as long as needed to deal with what they were about, and to keep a record of it.

8. How we protect it

Traffic is encrypted with TLS; stored data is encrypted at rest, and the credentials you connect are additionally encrypted by the application. Access to your AWS account is read-only unless your organization deploys the optional fix role. The details, and how to report a vulnerability, are on our Security page. No system is perfectly secure, and if a breach affects your personal information we will notify you and the authorities as the law requires.

9. Your rights

Depending on where you live, you may have the right to:

  • know what personal information we hold about you, and get a copy of it;
  • have it corrected or deleted;
  • restrict or object to how we use it, and receive it in a portable form;
  • withdraw consent where we relied on it;
  • opt out of the sale or sharing of personal information (we do neither); and
  • not be treated differently for using any of these rights.

To use them, email legal@socbinder.com. We will verify the request comes from you and answer within one month (GDPR) or 45 days (CCPA), telling you if we need longer. You may use an authorized agent; we will ask for proof of their authority. If the information is Customer Data, we will normally pass your request to the organization that controls it.

In the EEA, UK or Switzerland you may also complain to your local data-protection authority. We would appreciate the chance to put things right first.

10. Children

SOC Binder is a business service. It is not meant for anyone under 18, and we do not knowingly collect personal information from children.

11. Changes to this policy

If we change this policy we will update the effective date above, and for a material change we will tell account owners by email before it takes effect.

12. Contact

RuneSpoke Inc.
8 The Green, Suite G
Dover, DE 19901
United States
legal@socbinder.com

SOC Binder

SOC 1 and SOC 2 evidence collection for AWS. Not a CPA firm; issues no audit opinion.

Privacy PolicyTerms of ServiceCookie PolicySecurityComplianceSubprocessorsBeta Terms

© 2026 RuneSpoke Inc.