Example Cloud Apps LLC

Read this first

This is a starting policy set generated from the answers you gave. It is not a SOC 2 report, not an ISO 27001 certification and not legal advice, and it does not by itself make your company compliant with any framework, contract or law. Policies only count when you actually follow them: work through the gap list, correct anything that does not match how you operate, and have a qualified professional review it if a customer contract or regulation depends on it. Answer-sheet entries are drafts built from your own answers; check every one before you send it to a customer, because a wrong answer on a security questionnaire can breach a contract.

These policies were written for Example Cloud Apps LLC, a software-as-a-service company with 5 people, from the answers given on November 9, 2026. They are aligned to (not certified against) these frameworks:

• CIS Critical Security Controls v8.1 (Implementation Group 1 safeguards): https://www.cisecurity.org/controls/implementation-groups/ig1
• NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
• AICPA Trust Services Criteria (the SOC 2 criteria), common criteria CC1 to CC9: https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022

How to use this kit: 1) read each policy and fix anything that does not match how you work; 2) sign the approval page; 3) have everyone sign the acknowledgment; 4) work through the gap list by the dates shown; 5) use the answer sheet as a starting point for customer security questionnaires, checking every answer first.

Contents

• Gap list (what to fix, by when)
• Security questionnaire answer sheet
• Risk register
• Approval page and staff acknowledgment

P-01 Information Security Policy

Purpose

This policy sets out how Example Cloud Apps LLC protects the confidentiality, integrity and availability of its information and customer data, and who is responsible. All other policies in this set sit under it.

Scope

All employees, contractors and anyone else with access to Example Cloud Apps LLC systems or data, and every system that stores or processes customer data.

Responsibilities

• Alex Rivera (CEO) is accountable for information security and approves these policies.
• Jordan Lee (CTO) is the Security Lead: keeps these policies current, runs the reviews they require, tracks the gap list and is the first contact for any security question or incident.
• Every person with access must follow these policies, complete security training, and report anything suspicious straight away.

Security objectives

• Protect customer data from unauthorised access, change or loss.
• Give access only to people who need it, and remove it promptly when they no longer do.
• Detect and respond to security incidents quickly and tell affected customers as our contracts require.
• Keep services available and recoverable after an outage or data loss.
• Meet the security commitments we make in customer contracts and questionnaires, and answer them truthfully.

Core rules that apply everywhere

• Multi-factor authentication (MFA) is required on Google Workspace and every system that holds company or customer data.
• Credentials are stored in 1Password; passwords are never shared in chat, email or code.
• Company devices use full-disk encryption, screen lock and automatic updates.
• Customer data is encrypted in transit (TLS 1.2 or later) and at rest wherever the platform supports it.
• Security awareness training is given at onboarding and at least once a year.
• Security-relevant events are logged and reviewed; incidents follow the Incident Response Plan.

Risk management

• The Security Lead reviews security risks at least once a year and after any major change (new product, new vendor holding customer data, an incident), using the risk register in this kit.
• Risks are accepted, reduced, transferred or avoided by decision of the owner, and the decision is recorded.

Policy management

• These policies take effect on November 9, 2026 and are reviewed at least every 12 months (next review due November 9, 2027).
• Changes are approved by the owner and recorded in the version history. Staff are told about material changes.

Exceptions

Any exception to this policy needs the Security Lead's written approval, a reason, a temporary safeguard and an end date, and is listed in the risk register.

Enforcement

Breaking this policy may lead to loss of access and disciplinary action, up to ending employment or a contract.

Framework alignment

P-03 Access Control Policy

Purpose

This policy controls who can reach Example Cloud Apps LLC systems and data, and how access is granted, reviewed and removed.

Scope

All company systems, including Google Workspace, Amazon Web Services (AWS), GitHub and every SaaS tool that holds company or customer data.

Principles

• Least privilege: people get only the access their role needs, for as long as they need it.
• Every account belongs to a named person. Shared accounts are allowed only where a system cannot support named accounts, and their credentials live in the password manager with a named owner.
• Where a tool supports it, sign-in goes through Google Workspace (single sign-on) so access can be removed in one place.

Authentication

• MFA is required on every account with access to company or customer data, and on all admin accounts without exception. Authenticator apps or security keys are preferred over text messages.
• Passwords are at least 12 characters, unique per system and stored in the password manager. Forced periodic changes are not required; passwords are changed at once if compromise is suspected.

Privileged access

• Admin rights are limited to named people approved by the Security Lead, and are used through separate admin accounts or elevation where the platform supports it.
• Root or owner accounts in Amazon Web Services (AWS) are protected with MFA, are not used for daily work, and have their credentials stored in the password manager.

Joiners, movers and leavers

• Access is granted on a request approved by the owner or Security Lead and recorded in the access review table.
• When someone changes role, access they no longer need is removed within 5 working days.
• Leavers lose all access on their last working day: disable the identity account, revoke sessions and tokens, remove them from every system in the access table, rotate any shared credentials they knew, and collect or wipe company devices.

Access reviews

• The Security Lead reviews every account in every system at least every quarter, removes what is not needed, and records the date and result.

Exceptions

Any exception to this policy needs the Security Lead's written approval, a reason, a temporary safeguard and an end date, and is listed in the risk register.

Enforcement

Breaking this policy may lead to loss of access and disciplinary action, up to ending employment or a contract.

Framework alignment

P-07 Incident Response Plan

Purpose

This plan says how Example Cloud Apps LLC spots, contains and recovers from security incidents and who it tells.

Scope

Any event that may affect the confidentiality, integrity or availability of company or customer data: phishing that worked, a lost device, leaked credentials, malware, unauthorised access, or a vendor breach.

Roles

• Incident lead: Jordan Lee. Backup: Alex Rivera.
• Anyone who notices something suspicious reports it to the incident lead at once, by phone if it is urgent. Reporting early is never punished.

Steps

• 1. Report and record: open an incident record with the time, what was seen and who reported it.
• 2. Assess: decide whether customer data or systems may be affected and how serious it is (low, medium, high).
• 3. Contain: disable affected accounts, revoke sessions and tokens, isolate devices, rotate exposed secrets.
• 4. Fix and recover: remove the cause, restore from clean backups if needed, confirm systems work.
• 5. Notify: see below.
• 6. Learn: within 10 working days write a short review (what happened, why, what changes) and update the risk register.

Notifying customers and authorities

• Customers whose data is affected are told without undue delay and within the time their contract sets; where a contract is silent, the target is within 72 hours of confirming the incident.
• If personal information of Texas residents is breached, affected people are notified within 60 days, and the Texas Attorney General within 30 days if 250 or more Texans are affected (Tex. Bus. & Com. Code 521.053). Other states' laws apply for their residents.
• The cyber insurer (if any) is contacted before outside help is hired, as policies often require.
• Only the owner or someone they name speaks to customers, media or authorities about an incident.

Testing

• The plan is tested at least once a year with a short tabletop exercise, and updated after every real incident.

Contacts

• Incident lead: Jordan Lee
• Amazon Web Services (AWS) (Cloud hosting and infrastructure): support and security contact
• Google Workspace (Email, identity and collaboration): support and security contact
• GitHub (Source code hosting): support and security contact
• 1Password (Password and secret storage): support and security contact
• Microsoft Defender (Endpoint protection): support and security contact
• Stripe (Listed by us): support and security contact

Exceptions

Any exception to this policy needs the Security Lead's written approval, a reason, a temporary safeguard and an end date, and is listed in the risk register.

Enforcement

Breaking this policy may lead to loss of access and disciplinary action, up to ending employment or a contract.

Framework alignment

Sample ends here for policies. The Full kit continues with 11 more policies, written the same way around your tools.

Gap list

Your answers were checked against the policies. Each item below is something to do so the policies describe what Example Cloud Apps LLC really does. Dates count from the effective date.

Security questionnaire answer sheet

Draft answers built only from what you told us. Answers marked Yes assume you have adopted and follow these policies. Check every answer before sending it to a customer, and update it when a gap is closed. Never change a Not yet or No to Yes until it is true.

Sample shows 10 of 40 answers. The Full kit also includes the risk register, access review record, approval page and staff acknowledgment.

Starting policy set from Stratum Tech Group. Not a SOC 2 or ISO 27001 certification. Not legal advice.