Enforcing security and compliance within our nearshore teams

Can you trust the engineers that your nearshore partner assigns to your projects?

When companies hire a nearshore development partner, they're trusting an external team with their code, systems, and sensitive business information. Naturally, they want to know that their partner takes security and compliance as seriously as they do. Our goal is to give clients greater visibility into how we operate, so they can confidently work with our teams knowing that security and compliance are part of how we do business.
So, on October 5, 2026, our three co-founders signed the Ewents Trust and Compliance Charter, the founding document of our formal Trust and Compliance Program. It opens with a clear purpose: "Ewents exists to give its clients confidence that the people, processes, and information entrusted to it are handled with integrity, discipline, and care." Below, we walk through what our program covers, who is accountable for it, and what it means for the companies that work with our team.

Handling sensitive data and code is everyone’s responsibility

At Ewents, we provide dedicated nearshore engineering teams that often work directly within our clients' environments, with access to source code, development systems, and sensitive business information.
One of the main concerns that we frequently hear from clients when they want to engage our services is how we manage security within our teams. We often get asked, “How do we vet our engineers? What happens when they access sensitive information? Also, how do we make sure they follow the same security standards as our clients' internal teams?”
Especially for companies that are looking for a nearshore partner, these questions matter because our security responsibilities go beyond protecting our own infrastructure. As a services provider, we are also responsible for how we select, train, supervise, and hold our engineers accountable throughout each engagement. In other words, clients are not just trusting individual engineers. They're trusting Ewents as an organization.
That's why we've established our Trust and Compliance Program, guided by a commitment formally stated in our Charter: “Earning and keeping the trust of clients, partners, and employees is not a byproduct of doing business, but a condition of it.”
Our program establishes how we manage security, protect information, address risks, and maintain accountability across four key areas:

• Security: Protecting client, employee, and company information against unauthorized access, loss, or misuse, including how our teams handle sensitive information during client engagements.

• Privacy: Safeguarding personal information belonging to our employees, candidates, and individuals whose data we process on behalf of clients.

• Risk Management: Identifying, assessing, and addressing operational, human, and information-related risks, including those that come with working across external development environments.

• Compliance: Meeting our commitments to clients, regulators, and our own staff, while documenting our policies, controls, and processes to demonstrate compliance with client requirements.

Who is accountable at Ewents

In our Trust and Compliance Charter, we clearly established that our leadership team is fully accountable for every security and compliance decision within the company. All three co-founders, Matias Jacob (CEO), Tomas Fleitas (CTO), and Pablo Mascaretti (CRO), formally signed the Charter, committing Ewents to providing the resources, support, and oversight needed to make the program effective.
To protect clients, we’ve established a governance structure that ensures security and compliance remain priorities across the organization:

• Board of Directors: Reviews our overall risk posture and ensures security and compliance are considered in the company's strategic decisions.

• Executive Team: Supports the program, allocates resources, and makes security and compliance an organizational priority.

• Risk Committee: Meets regularly to review security, risk, and compliance matters and escalates issues that require executive decisions.

• GRC Director: Leads the program day-to-day, maintains our internal policies, oversees compliance activities, and reports directly to our CEO.

To expand on the point above, we’ve assigned a GRC Director who reports directly to the CEO to keep security and compliance visible at the highest level of the company and to connect our governance policies with the engineering and security teams that implement controls. In fact, we apply the same philosophy of embedding GRC into engineering teams within our own organization. To operationalize GRC within Ewents, our Charter explicitly requires our Board and executive team to provide the necessary resources, communicate security expectations across the company, and actively support our GRC Director.

We follow SOC 2 as the main reference framework

Our main compliance objective is SOC 2, the AICPA's Trust Services Criteria. It maps directly to what our clients care about: the security, availability, confidentiality, and privacy of the information we handle on their behalf, and the integrity of the practices behind it. Additionally, our policies cite the specific SOC 2 criteria and framework controls behind each requirement. For companies evaluating a nearshore engineering vendor, SOC 2 provides a useful reference for reviewing how security responsibilities and controls are documented. Our program uses those criteria to guide internal policies, risk assessments, and compliance evidence.
Our team also tracks a wider set of frameworks as reference points and potential future milestones: ISO/IEC 27001 and the NIST Cybersecurity Framework 2.0 for information security, ISO 31000 for risk management, ISO 22301 for business continuity, ISO/IEC 27701 for privacy, and ISO/IEC 42001 together with the NIST AI Risk Management Framework for AI governance. We also regularly review the regulations and client contract requirements that apply to Ewents, so our program reflects our real obligations rather than a generic checklist. Our Charter calls this a layered approach: "a clear main commitment supported by broader awareness of the wider compliance landscape." Broadly speaking, this commitment gives our company a mature, deliberate posture today and room to expand our program as we grow.

Ewents follows 12 clear security and compliance policies

To put our Trust and Compliance Charter into practice, we've established ten policies and two plans that define how we manage security, compliance, and risk across Ewents. Together, these documents form the Ewents Policy Library. On one hand, our policies establish the rules, responsibilities, and controls our teams must follow in their day-to-day work, covering everything from hiring and data protection to access management and responsible AI use. On the other hand, our plans define how we respond to security incidents and maintain business continuity when unexpected disruptions occur. Below, we explain the twelve areas it covers and how they apply to our internal operations and client engagements.

1. Hiring and background checks

Personnel security is a central part of our program because our engineers often work directly within clients' systems and handle confidential information. We follow a structured recruitment process where every candidate undergoes a technical interview conducted by experienced engineers, followed by a review of the interviewer's evaluation by our management team before making a hiring decision.
Additionally, we conduct background checks on professionals assigned to client engagements before their assignments begin, subject to our documented exception process. For checks involving criminal records, we require the candidate's explicit consent and handle the results with strict confidentiality.

2. Onboarding, training, and professional conduct

We require every professional joining Ewents to complete a documented onboarding process that establishes their responsibilities, confidentiality obligations, and security expectations. Each team member signs a role-specific job description and confidentiality agreements, acknowledges our Information Security and Human Resources policies within their first week, and completes security, privacy, and ethics training within 30 days of joining, followed by annual refresher training.
Furthermore, our Code of Conduct defines the standards of professional integrity we expect from everyone at Ewents, including requirements around conflicts of interest, anti-corruption, and acceptable workplace behavior. We also maintain a confidential whistleblowing channel where our employees can report suspected misconduct, with protections against retaliation and procedures for investigating concerns we take any disciplinary action.

3. Access management

Our approach to access management follows the principle of least privilege, meaning our engineers and contractors should only have access to the systems and information necessary to perform their assigned responsibilities. We document every access request, modification, and removal, require multi-factor authentication for remote access and systems containing confidential information, and restrict privileged accounts to authorized personnel.
Additionally, our team maintains an access matrix that we formally review at least once a year to ensure permissions remain appropriate. When someone leaves Ewents, we revoke their access within 24 hours of their last working day and immediately notify any affected clients.

4. Information security and confidentiality

We classify the information our company handles into four categories: Public, Internal, Confidential, and Secret, with specific requirements governing how each category is accessed, stored, transmitted, and protected.
To safeguard confidential information, we require encryption in transit and at rest and establish controls for data masking, unauthorized downloads, and potential information leakage. We also protect our clients' intellectual property with at least the same level of care that we apply to our own confidential information.
Furthermore, we prohibit our engineers and contractors from using personal accounts or unapproved external services to store or process Ewents or client information.

5. Privacy and data protection

Our Privacy Policy is aligned with SOC 2, references ISO/IEC 27701, and considers regulations such as the GDPR and CCPA wherever applicable.
We maintain documented records of personal data processing activities, including their purposes, legal bases, assigned responsibilities, and retention periods. We also apply fundamental privacy principles such as data minimization, purpose limitation, and accountability to how our company handles personal information.
Additionally, we conduct privacy impact assessments at least annually and whenever significant changes to processing activities occur, while maintaining procedures for responding to data subject requests and potential privacy incidents. On client engagements, our engineers must follow each client's documented instructions, contractual obligations, and applicable data protection requirements.

6. Secure software development

Our Information Security Policy establishes requirements for integrating security throughout the software development lifecycle, including change management, code reviews, testing, configuration management, and release procedures.
We require our engineers to document and version changes to code, infrastructure, and configurations so that every change is traceable, independently reviewed, and tested before deployment. Additionally, we maintain separate development, testing, and production environments and require security risk evaluations before implementing high-impact changes.
These practices reflect the same principles we apply through our secure software development services services, while allowing our teams to incorporate the additional security requirements established by each client.

7. Vulnerability management

To identify security weaknesses before they can be exploited, we've established regular vulnerability scanning, assessment, and remediation requirements. Our policies define the following minimum scanning frequencies:

• Source code: Before every merge into a shared branch.

• Web applications: At least once a month.

• Infrastructure: At least once a week, including vulnerability and misconfiguration scanning.

Our security and engineering teams prioritize findings according to severity, follow defined remediation timelines, and track identified vulnerabilities until they are resolved or formally accepted as documented risks.
Additionally, we establish requirements for web application firewalls, rate limiting, DDoS protection, centralized security logging, and ongoing monitoring. These practices are consistent with the risk-based approach we provide to clients through our vulnerability management services.

8. Responsible AI use

As AI tools become increasingly integrated into software development, we recognize the importance of establishing clear guidelines for how our engineers use them. That's why we've developed an AI Governance Policy that defines how we evaluate, approve, and monitor AI tools across Ewents, referencing ISO/IEC 42001 and considering the risk classification principles of the EU AI Act.
Before approving an AI tool, our team evaluates its intended purpose, assigns an owner, assesses potential risks, and defines the information and systems it can access. We also require human oversight of AI-generated outputs before using them to make decisions that could meaningfully affect our company, clients, or individuals.
Most importantly, our engineers must follow each client's AI usage policies, and we strictly prohibit submitting client information to AI systems not explicitly approved by that client.

9. Third-party and vendor security

Just as our clients evaluate Ewents before working with us, we also evaluate the third parties that support our operations. Our Third-Party Risk Management Program establishes how we assess, approve, and monitor vendors that provide services to our company or may have access to confidential information.
We maintain an inventory of our vendors and classify each provider according to the criticality of its services and the sensitivity of the information it handles. For our highest-risk vendors, classified as Tier 1, we conduct more extensive due diligence and annual compliance assessments, considering independent assurance evidence such as SOC 2 reports or ISO/IEC 27001 certifications.
Furthermore, we require vendor agreements to establish clear security obligations, incident notification requirements, and procedures for returning or securely disposing of information when a business relationship ends.

10. Risk management and financial integrity

Managing risk across our organization requires clear responsibilities, documented processes, and regular oversight. Our risk management program covers operational, human, financial, and information security risks through periodic assessments, documented risk registers, assigned responsibilities, and ongoing monitoring of corrective actions.
Additionally, we've established an Anti-Fraud and Financial Governance Policy that requires annual fraud and corruption risk assessments, financial oversight by our leadership team, external accounting support, and independent investigations when misconduct is suspected.
We also maintain controls over how contractor hours are reported and billed. Our contractors must document their working hours against specific projects, and our management team reviews and approves those hours before we invoice clients, helping us maintain financial transparency and accountability.

11. Incident response

We've established an Incident Response Plan that defines how our company identifies, reports, classifies, contains, investigates, and recovers from security incidents. Our team classifies incidents according to three severity levels: High, Medium, and Low, with high-severity incidents requiring direct involvement from our executive leadership and coordination with the relevant engineering and security teams.
For every declared incident, we document what happened, conduct a root cause analysis, and identify corrective actions to strengthen our existing security controls. We also review incident trends through our Risk Committee to identify recurring issues and opportunities to improve our response procedures.
Furthermore, when an incident affects a client's environment, our engineers and security specialists cooperate with the client's response team according to the responsibilities and notification requirements established in our agreement.

12. Business continuity

Our Business Continuity Plan defines how we prepare for operational disruptions and maintain the availability of critical services. It includes annual Business Impact Analyses, recovery objectives, internal system backups, and periodic testing to evaluate our ability to respond to unexpected events.
Because our business depends primarily on the professionals assigned to client engagements, personnel continuity is particularly important to us. We maintain an active network of qualified engineers and commit to identifying suitable replacements as soon as reasonably possible when assigned professionals become unavailable, while encouraging knowledge sharing across our teams to reduce operational dependencies.
Finally, we test our Business Continuity and Incident Response Plans at least annually and maintain cyber liability insurance as an additional measure to manage certain financial risks associated with security incidents.

Our company enforces accountability and transparency

We maintain accountability across our security and compliance program through regular policy reviews, formal risk assessments, and ongoing audits to verify our controls work as intended. To make this effective, we've established clear responsibilities across our leadership, GRC, and engineering teams, along with documented processes for reviewing risks, tracking compliance, and addressing issues that require corrective action.
Our accountability framework includes several important practices:

• Policy reviews and approvals: Every policy and plan must be independently reviewed by someone other than its author and formally approved by a member of our executive leadership team. We maintain records of these approvals and review all documents at least annually, or sooner when significant changes to our business or risk profile require it.

• Risk ownership and oversight: We evaluate risks using a five-by-five scale that measures likelihood and potential impact, and we record each risk in a register with an assigned owner and treatment plan. Our risk appetite is deliberately low, meaning risks rated above Low require treatment, and any remaining exposure above that threshold must receive formal acceptance. Additionally, our Risk Committee meets at least quarterly to review identified risks, treatment progress, and outstanding corrective actions.

• Continuous compliance monitoring: Our GRC team monitors the evidence supporting our security and compliance controls, tracking whether documentation is current, outdated, or missing. Our management team receives monthly compliance reports, and we formally review every control at least once a year to verify that its supporting evidence remains valid.

• Corrective actions and accountability: Whenever we identify a security or compliance gap, we document the finding, assign an owner, establish a corrective action, and set a target completion date. Our GRC Director must verify that the issue has been addressed before the finding can be formally closed.

In addition, our Audit Management Policy requires an annual SOC 2 self-assessment, an annual gap assessment against another recognized framework, and an independent SOC 2 examination to assure clients that our documented controls are operating effectively and to identify areas where our program needs improvement.
Finally, when a team cannot meet a specific security or compliance requirement, we require a formal exception process rather than allowing the requirement to be disregarded. Every exception must be documented, approved by our GRC Director or executive leadership, supported by an appropriate compensating control, and assigned an expiration date so that every exception remains visible, is reviewed regularly, and cannot remain in place indefinitely.

What clients can expect when engaging Ewents

When you engage Ewents to hire a dedicated engineering team from Latin America, you can expect our team members to follow documented security and compliance requirements, protect your confidential information, and remain accountable throughout the engagement. Our engineers often work directly within our clients' environments, so we've established clear security standards for how we select professionals, manage access, handle sensitive information, and address potential risks.
Additionally, we recognize that every client has different security and compliance requirements. While our baseline policies apply across Ewents, we work with each client to understand the additional controls required for their systems, infrastructure, and regulatory obligations. When a client's requirements are stricter than our own, those requirements take precedence, and our engineers must follow the applicable access, endpoint security, and data-handling controls.
Beyond these requirements, clients can expect clear procedures and responsibilities throughout the engagement, particularly when unexpected situations arise:

• Security incidents: If an incident affects your information, we notify you according to the timelines established in our agreement and cooperate with your incident response process.

• Personnel continuity: If an assigned engineer becomes unavailable, we commit to identifying a suitable replacement as soon as reasonably possible to minimize disruption to your project.

• Access and offboarding: When an engineer assigned to your team leaves Ewents, we notify you immediately and revoke their access within our established offboarding timeframe.

Overall, our goal is to provide engineering teams you can trust with your sensitive data and critical systems. Reach out to our team to learn how Ewents can support your engineering needs while meeting your security requirements.

Frequently Asked Questions (FAQ)

• What security and compliance requirements should companies look for in a nearshore engineering partner?

  Companies should review how a vendor handles background checks, confidentiality agreements, access controls, data protection, incident response, and third-party risks. They should also ask how those controls are documented and reviewed. At Ewents, our Trust and Compliance Program establishes a security baseline, while each client can define additional requirements for its engagement.

• How does SOC 2 fit into Ewents' Trust and Compliance Program?

  SOC 2 is the primary compliance objective of our Trust and Compliance Program. Our policies reference the applicable Trust Services Criteria, and our Audit Management Policy establishes requirements for internal assessments and independent examinations. We use these criteria to guide our security controls, risk management, and compliance documentation.

• How does Ewents vet engineers before assigning them to client projects?

  Our hiring process includes technical interviews and management review. Our policies require background checks before assigning professionals to client engagements, subject to applicable legal and consent requirements. Engineers must also sign confidentiality agreements, acknowledge security policies, and complete mandatory security, privacy, and ethics training.

• How does Ewents protect client data when engineers work remotely?

  Our Information Security Policy establishes requirements for confidentiality, access management, multi-factor authentication, and secure information handling. When a client sets specific device, network, or access requirements, we incorporate those requirements into the engagement. The agreed responsibilities determine how we manage client-system access.

• Do Ewents engineers follow the client's security policies?

  Yes. Our engineers must follow Ewents' internal security requirements and the applicable requirements set by each client. Where contractual requirements are stricter, those take precedence, subject to the documented exception process. This allows our dedicated teams to work within each client's security environment.

• Can Ewents engineers use AI tools with client information?

  Only under the client's approved conditions. Our AI governance policy requires internal AI tools to undergo review and approval, with defined ownership, data-access limits, and human oversight. On client projects, our engineers follow the client's AI rules and cannot enter client information into unapproved AI tools.

• What happens if a security incident affects client information?

  Our Incident Response Plan establishes procedures for detection, triage, containment, and recovery. If an incident affects client information, we notify the client within the timeframe established in its contract and cooperate with its incident response process. The plan also requires incident documentation and follow-up corrective actions.