The recipe behind certification
The B2B company can achieve a certification by implementing proper security measures, establishing the best practices and policies and gathering evidence. One of the artefacts is the Penetration Testing report, meaning the company needs to hire a partner which is able to perform it and make an appropriate report. Hiring a partner also helps with the checklist on all the practices, policies and evidences. There is no short-cut to a certification though, but hard work pays off.
Once every piece of evidence is gathered, the external auditor goes through them and generate a compliance report which we can share with the clients then. But why going through such a hassle in the first place?
Why SOC2 matters for a B2B tax platform
In B2C software, say a mobile application, the compliance required converges on a privacy policy, terms of service and age assessment. The corporate clients can’t be the more opposite than that, especially for Supplied AI, where we work with Personal Identification Information(PII), tax IDs, bank account numbers, and identity documents for a DAC7 and 1099K reporting product. Our customers are platforms and marketplaces. Those customers face their own regulators. Before they sign a contract with us, their security teams need proof that we protect this data correctly. And even then the process takes weeks and months. And while the certificate proofs formal compliance, it does not close the deal by itself - the actual controls behind the certificate do.
Before I became a CTO at Supplied, I got a taste of certification during my time in Bolt while leading Billing team in the Commerce Department. I had to fill some forms and questionnaire, but boy, did I not realize the whole scale of getting the whole company certified.
This article walks through the main control areas that SOC2 and ISO27001 check. Each section names the control area, then shows the real system behind it.
How the assessment happens
Your verification partner runs a software solution which solve several issues during certification:
- Managing certifications
- Finding gaps
- Gathering evidence
- Manage reviews&approvals
- Providing TODO lists
- Handling evidence life-cycles
However the biggest advantage of such a platform is the cloud integration: as we run AWS, our certification partner was granted the read-only access to our AWS organisations so the software could scan it and find the gaps. Imagine doing the same with on-prem resources ;)
But what the scanning is looking for?
Access control
First area of interest of the certification is access control: how our customers access their data and how this data is separated from other customers. Essentially, everyone wants to know that one client does not see the data of the other ones. The system can’t just rely on the 3rd party partner for authorisation and call it a day. Here’s how we do it at Supplied.
Supplied works with types of end users: suppliers(sellers) - think drivers, couriers, goods sellers, content creators; and administrators - members of staff of the marketplaces the suppliers operate on. We split those groups with audiences in Auth0: different applications, different keys, completely different permission models.
Admin-only endpoints carry an extra guard. The guard checks for the admin authentication strategy by name. A supplier token cannot reach these routes, even by mistake due to audience separation.
However separating people by a role is not enough; the admins should only have access to their own data, and nothing else. That’s why every request in the admin panel is scoped, so every database query for company data carries this scope. The system reads a company ID from the request context and applies it to the query. One company cannot read data that belongs to another company, as the query uses the company id from the authorization, not request parameters.
Other problem is the malicious or accidentally incorrect input. We validate everything with built-in Nest.js mechanism, so input validation runs on every write automatically. The validation pipe keeps a list of allowed fields and rejects any request with fields outside that list. This stops a common class of data-tampering attempts before the request reaches business logic.
Encryption and key management
While access control secures the data within legitimate users, encryption is what makes the data safe against everybody else. In case of traffic interception, or database leakage any data should remain useless to the attacker. Here’s the set of security measures we take.
Our customers data is of outmost priority. Data at rest uses AES-256 across S3, RDS, and DynamoDB. Data in transit - the traffic between the frontend and backend - uses TLS. The database proxy requires TLS on every connection. The developers can not access the database without a VPN tunnel, which uses mutual TLS with its own certificate authority.
However encryption is not a silver bullet, but rather one of the many measures we leverage. The web applications(and we run 2 in production) are a subject to multiple different techniques like XSS, protocol downgrade attacks, and many others. Fighting them means sending a whole set of HTTP headers so that the customer’s browser can prevent undesired behaviour.
We add security headers in layers. The CDN edge sets a Content Security Policy, a Referrer Policy, a Strict-Transport-Security header, an X-Content-Type-Options header, and an X-Frame-Options header.
The application layer sets its own Content Security Policy too, with a per-request nonce. Two layers add a small amount of duplication. Two layers also mean that one misconfigured layer does not remove the protection completely.
Last, but not least: the access to the data storage and downstream systems. meaning API keys, access tokens, connection strings etc. They should be never written anywhere in a plain text: how reckless would be storing these secrets in files or environment variables! Instead, we encrypt secrets with AWS KMS before any service uses them.
Change management and the software development lifecycle
The main principle of the secure change management:
Each change in the solution should be caused by a legitimate business need and have a clear trace.
Essentially, you need to ask a question “Why this change happened?” and “Who made it?”. That’s why there are no changes without a link to an issue in our Task Tracker system(we use Linear). But having tickets does not do the trick: the pipeline delivering changes is required too.
What to expect from a pipeline? A good one is:
- Predictable. Run on the same version, get same result
- Secure. Avoid leaks, prevent supply chain attacks.
- Helpful. Catch quality problems before it reaches any environment.
To grant aforementioned properties, we configured out delivery pipeline in the following manner.
Every deploy pipeline uses short-lived cloud credentials. GitHub Actions requests a token through OpenID Connect at run time. No long-lived AWS key sits in any repository secret.
Every pull request runs through a merge gate. The gate runs lint checks and a full test suite. The integration tests run against a set of emulated storages we use.
Every container image gets scanned on push, before it reaches any environment. A vulnerable base image gets flagged at build time, not after deployment.
We have 2 environments: staging and production. The tickets reach staging and being thoroughly tested. Only then the changes are deployed to prod.
Monitoring and incident response
Once the code is on the production, the working phase begins. At this point SOC2 asks a direct question: when something breaks, how does the team find out? What happens next? We answer with the set of monitoring tactics alongside measures applied for the identified gaps.
Our monitoring stack is classic, if not boring. CloudWatch for logs and alerts, Sentry for crash reporting, CloudTrail for audit. The team is monitoring the email alerts and reacts to urgent one ASAP; we configured Sentry for the Linear integration so independent of urgency we make a ticket in Linear right away to follow our change management policies.
But logic fixes is one story; real incidents is another. We had an incident when after one of the migrations we completely broke the Supplier App. After getting the indication from Sentry we indeed delivered a hotfix, but the interesting part is indeed in the Post Mortem.
We follow the best practices regarding learning from our own mistakes: The incident owner filled in the Post Mortem template, and then we hold a meeting to analyze it, make the remediation measure to later implement them.
Vendor and third-party risk
Customers data does not flow only through our applications and data storages, it is processed by external downstream systems. The formal term for them is “Subprocessors”. Data Protection standards and legislations demand at least a disclosure on these lists; the ideal situation includes minimisation of data processed alongside data locality. Meaning? Don’t transfer data oversee, but if you do - make sure there is no sensitive info transferred.
Supplied connects to more than fifteen outside services. These include payment processors, crash reporting software, an email provider, tax authorities in multiple countries, identity verification providers, and indeed hosted LLMs for AI payloads.
Here are our principles:
- Use EU data residency to the maximum. Auth0 leverages EU tenants for both staging and production, EU-based models in AWS Bedrock, compute and storage resources are located in EU regions too.
- Use minimum amount of information, avoid PII. Crash reporting software for example anonymise everything, customer emails are not included replaced by non-PII user ids, all the text on crash-associated screen recording is masked.
- Be explicit about your subprocessors.
Not to mention, the clients ask about subprocessors and data locality every second time, so having this in order is essential.
Policies and Trainings
Reading the article so far you could have thought that certification is about technical measures, it is definitely not true. The organization should adopt several dozens of policies on hiring(onboarding and offboarding), access controls, communication, security trainings, backups, data retention and other aspects of software business.
Templates help to draft the policies, but real work is filling them in and proving they are actually in place instead of dead documents.
Consider the policy of running background checks: the organization should provide the proof, that criminal records were actually checked for the employees, their education suits the role and the employees have the skills corresponding to their roles.
The same affects the board meeting policies: it’s not sufficient to state the board should gather at least once a months; a proof of scheduled meetings and written meeting minutes are required. Thanks tech gods, we have automated summary nowadays.
Final Steps
Once the security measures are complete, evidence gathered and the pen-test conducted(with the gaps closed), it’s time to get an external auditor going through evidence. In our case our certification partner ordered this audit on our behalf and shared all the findings. Then you just wait for 2-3 weeks and get your SOC2 report.
I hope you can pass your certification as well. If you need a contact of the certification partner, leave a comment down below, I will refer your company.
Our Offering
Running a digital marketplace? Struggling with supplier onboarding and DAC7 reporting? Nervous about safety of the sellers data? Checkout Supplied AI - compliance infrastructure for Digital Marketplace. Get compliant in no time!
