Finding Your SOC 2 Starting Line: A Scoping Story
How a 10-person e-waste startup approached their first SOC 2 Type II audit without breaking the bank
Sarah drummed her fingers on her desk, staring at the email from her biggest prospect yet. TechCorp wanted to send 500 decommissioned servers to GreenCycle for secure data destruction and recycling. The contract would triple her revenue. There was just one problem.
“We’ll need to see your SOC 2 Type II report before we can proceed.”
GreenCycle had been in business for 18 months. Ten employees. No board of directors. No compliance officer. Just Sarah (CEO), two logistics coordinators, four technicians who handled the actual e-waste processing, two sales reps, and an accountant who came in twice a month.
Sarah had heard about SOC 2, but always figured it was something for “later” — when they were bigger, more established, had a real office instead of a warehouse with a corner desk area. But TechCorp wasn’t the first client to ask. If GreenCycle wanted to move beyond small business clients and tap into enterprise contracts, SOC 2 wasn’t optional anymore.
The question was: where do you even start?
The Scoping Conversation That Changed Everything
Sarah called her friend Marcus, who ran a small security consultancy. “I need SOC 2,” she told him. “But I keep reading about these massive implementation projects, governance committees, and hundreds of controls. We’re ten people, Marcus. We don’t have a board. We don’t even have an HR department.”
Marcus laughed. “Sarah, you don’t need to boil the ocean here. You need to scope your audit to what actually matters for your business. Let me ask you something: what does GreenCycle actually do with client data?”
“We track what comes in — asset tags, serial numbers, client information. We document the destruction process. We provide certificates of destruction. Everything’s in our system.”
“Okay. And where does that happen?”
“Our warehouse in Oakland. We have a small office area, but most work happens on the floor — receiving, processing, documenting.”
“Any remote work?”
“Sales team works from home. I work from everywhere. The accountant is remote.”
“Cloud services?”
“We use Google Workspace. Our tracking system runs on AWS. We use Stripe for payments. That’s pretty much it.”
Marcus pulled out a notepad. “This is your scope, Sarah. This is what you’re actually protecting for your clients, and this is what an auditor needs to examine. Everything else? Out of scope for now.”
Mapping GreenCycle’s SOC 2 Scope
Over the next hour, Marcus helped Sarah map out what would actually be included in GreenCycle’s first SOC 2 Type II audit:
In Scope:
The Service: Client data intake, tracking, secure destruction, and certificate generation
The System: Their custom tracking platform (hosted on AWS), Google Workspace, and Stripe
The People: All ten employees who touch client data or the systems that process it
The Locations: The Oakland warehouse and remote work locations for sales team
The Data Flow: From client submission through tracking, processing, documentation, and certificate delivery
Explicitly Out of Scope:
Physical security of the warehouse (beyond basic controls for the office area where computers were kept)
E-waste recycling processes themselves (that was a different certification)
Financial systems beyond what was needed for audit logging (the accountant’s QuickBooks setup wasn’t handling client data)
Future plans for a customer portal (didn’t exist yet)
“But wait,” Sarah interrupted. “Doesn’t SOC 2 require a board of directors? Doesn’t it require separate security and compliance teams?”
“No,” Marcus said firmly. “SOC 2 requires effective controls. It doesn’t prescribe your organizational structure. You’re small. That’s fine. What matters is that you can demonstrate you’re doing the right things consistently.”
The Baseline Control Set
Marcus helped Sarah understand that for a company GreenCycle’s size, pursuing Trust Services Criteria with a focused scope, they could start with a manageable set of controls:
Security (required for all SOC 2 audits):
Access controls for their tracking system and Google Workspace
Password policies and multi-factor authentication
System monitoring and logging
Regular security updates
Vendor security assessments for AWS and Stripe
Basic incident response procedures
Background checks for employees handling sensitive data
Confidentiality (relevant for GreenCycle’s service):
Non-disclosure agreements with employees
Secure data destruction procedures
Encryption for data in transit and at rest
Secure certificate delivery to clients
Sarah noticed what was missing from the list: no change advisory board (they used a simple Trello board for tracking system updates), no formal risk committee (Sarah reviewed risks quarterly with her leadership team of three), no dedicated security operations center (they used AWS CloudWatch and set up basic alerts), no disaster recovery site (they had AWS backups and a documented recovery process).
“This doesn’t look like the SOC 2 requirements I’ve been reading about,” Sarah said.
“That’s because most SOC 2 content is written by enterprise consultants for enterprise companies,” Marcus explained. “The actual Trust Services Criteria are principles-based, not prescriptive. They say you need to identify risks, implement controls, and monitor effectiveness. They don’t say you need a 40-person security team to do it.”
Making It Work Without a Board
One thing kept nagging at Sarah: “Every policy template I’ve found references board oversight and board approval. We don’t have a board. Does that kill this whole thing?”
“Not at all,” Marcus assured her. “You need governance and oversight, but it doesn’t have to be a formal board. Who owns the company?”
“I do, completely. I’m the founder and sole owner.”
“Perfect. You’re the ultimate authority. You can act as the governing body. Your policies will say something like ‘The CEO, acting as the governing authority for GreenCycle, reviews and approves all information security policies annually.’ You’ll document those reviews. You’ll show the auditor that you’re making informed decisions about risk and controls.”
Sarah felt the weight lift a bit. “So I just... approve things?”
“You govern things,” Marcus corrected. “You make informed decisions about what risks to accept, what controls to implement, and how to allocate resources. You document those decisions. You review them periodically. That’s governance. A board of directors would do the same thing — you’re just doing it as the CEO because you are the highest authority in the company.”
For management review meetings, Sarah would involve her three key people: the Operations Manager (who oversaw the warehouse), the IT contractor who managed their systems, and the Sales Director. Together, they’d review:
Security incidents and near-misses
Access reviews (who had access to what)
Vendor assessments
Policy effectiveness
New risks from business changes
“Document those meetings,” Marcus advised. “Take notes. Track action items. That’s your evidence that you’re actively managing your security program.”
The Six-Month Journey
Marcus laid out a realistic timeline for GreenCycle’s first SOC 2 Type II:
Months 1-2: Foundation and Documentation
Finalize scope with the chosen auditor
Document policies (information security, acceptable use, access control, data classification, incident response)
Implement any missing technical controls
Set up evidence collection processes
Months 3-8: The Observation Period
Live with the controls for six months (minimum for Type II)
Collect evidence continuously
Conduct monthly access reviews
Hold quarterly management reviews
Document any incidents or exceptions
Months 9-10: Audit
Auditor testing and fieldwork
Respond to auditor questions
Remediate any findings
Receive the SOC 2 report
“Ten months total,” Sarah said. “That’s actually doable.”
“It’s doable because you’re being realistic about scope,” Marcus emphasized. “You’re not trying to implement every control in the NIST Cybersecurity Framework. You’re implementing the controls that make sense for protecting client data in your specific business model.”
What “Light Scoping” Really Means
As Sarah worked through the scoping process, she realized “light scoping” didn’t mean “weak security.” It meant:
Focus on what matters: Client data protection for e-waste services, not every possible security control that could theoretically apply
Right-size your controls: Multi-factor authentication and password policies instead of enterprise single sign-on and privileged access management systems
Document what you actually do: Their weekly team huddles where they discussed any security issues became “management security review meetings” once they started taking proper notes
Scale appropriately: Their three-person leadership team reviewing quarterly risks was just as effective as a large company’s formal risk committee — it was just smaller
Be honest about limitations: GreenCycle’s SOC 2 report would include a clear description of what was in scope. Clients would know exactly what was being attested to.
The Payoff
Eight months later, Sarah received GreenCycle’s first SOC 2 Type II report. Clean opinion. No exceptions.
More importantly: she understood her own security program. The scoping process had forced her to think clearly about what GreenCycle was promising clients, what systems delivered on those promises, and what could go wrong. The controls weren’t busywork — they were genuine protections that made the business more reliable.
The TechCorp deal closed. Then three more enterprise contracts followed in the next quarter.
“Best part?” Sarah told Marcus over coffee. “We’re not scrambling. When larger clients ask about our security program now, I can actually explain it. When they ask about our board oversight, I explain our governance structure and they get it. When they want to know about our scope, I can articulate exactly what we protect and how.”
“That’s what good scoping does,” Marcus said. “It gives you clarity. Not just for the auditor, but for your business.”
Lessons for Your First SOC 2 Scope
If you’re approaching SOC 2 from a similar position — small team, no formal board, limited budget — here’s what GreenCycle’s experience teaches:
Start with your service: What are you actually promising clients? What data are you handling? What systems deliver your service? That’s your scope.
Don’t scope for the company you want to be: Scope for the company you are today. You can expand scope in future audits as you grow.
Governance doesn’t require a board: It requires informed decision-making and documented oversight. A CEO can provide both.
Use your size as an advantage: Smaller teams can often implement controls more quickly and consistently than large, siloed organizations.
Be explicit about boundaries: Clearly document what’s in scope and what’s not. This protects you and sets accurate expectations for clients.
Your first audit is about learning: Yes, you need the report for clients. But the real value is understanding your own security posture and building controls that scale.
Ready to scope your first SOC 2 audit? PolicyCo’s platform helps organizations of any size document their scope, map controls to Trust Services Criteria, and maintain the evidence auditors need — without enterprise complexity. Schedule some time with us to see how policy lifecycle management can support your compliance journey from day one.