SOC 2 program

This section is the SOC 2 program for Rang & Mall Private Limited. It sits beside the compliance playbook and does not replace it. The playbook answers "is this lawful and honest". This section answers "can an independent auditor confirm that our security controls exist and work". Most rules overlap. Where they do, this section points to the playbook instead of restating it.

What SOC 2 is#

• An attestation report, not a certificate. A licensed CPA firm examines our controls against the AICPA Trust Services Criteria (TSC 2017, revised points of focus 2022) and issues a report under attestation standards AT-C 105 and AT-C 205. There is no "SOC 2 certified" and no SOC 2 badge that we can award ourselves.
• Type I says the controls were suitably designed at a single date. Type II says they also operated effectively over a period, usually 3 to 12 months. Business customers ask for Type II. A Type I is a reasonable first step.
• Scope is ours to choose. We pick the system (which products, which infrastructure, which people) and the criteria. Security (the Common Criteria, CC1 to CC9) is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional.
• The report goes to customers under NDA. It contains our system description, the auditor's opinion, every control, every test, and every exception the auditor found.

What SOC 2 is not#

• Not a law. No regulator requires it. Customers do, mainly US and UK businesses buying SaaS.
• Not proof of security. It is proof that we do what our documents say, which is why the documents must describe what we actually do.
• Not something an AI agent, a policy template, or this site can grant. Writing these pages is step one of about seven. See the roadmap.

How the pieces fit#

Two internal documents are deliberately not published: the gap assessment and the risk register. They describe weaknesses in our infrastructure and live only in the source repository under soc2-internal/. Share them with the auditor under NDA, never on this site.

Principles#

1. Write down what we do, then do what we wrote. A policy that describes an aspiration fails the audit as an exception. If a control does not run yet, the policy says so with a date, or the control is not in the matrix.
2. Evidence is a by-product, not a project. Every control names the artifact it leaves behind (a merged pull request, a log line, a signed review). If a control leaves nothing behind, it did not happen.
3. Automate before we document. A cron job that exports the access list monthly beats a calendar reminder that a person ignores.
4. One program for every app. Controls are company-level. An app joins the audited scope by meeting the scope entry criteria in 01, not by writing its own policies.
5. Small team, real separation. Auditors accept a small team. They do not accept one person approving their own production changes with nobody ever looking. Where two people are not available, a documented after-the-fact review is the compensating control.
6. AI agents are not users and not reviewers. Every action a coding agent takes in production belongs to a named human and is logged. An agent's approval of its own change is not a review. See 17 AI coding agents.

Owners#

Fill these in before the first policy is signed. A role may be held by the same person as another role, except that Change Approver and Change Author may not be the same person for the same change.