Built to Be Trusted: Security and Privacy at TiVaMo
At TiVaMo, privacy and security have been part of the way we have built the platform from the beginning. We have tried to make practical choices about what data we collect, where it is stored, and who or what can access it.
The information people trust us with can be highly personal. Financial data can reveal a great deal about a person's family, priorities, obligations and plans. If we ask people to share that information with us, protecting it has to be part of the architecture as well as the policies that describe how we use it.
Friction on purpose
The technology industry has spent years removing clicks and checks between a person and an app. Often that improves the experience. In some places, though, an extra verification step is appropriate.
Today, TiVaMo uses identity verification during onboarding, explicit acceptance of applicable legal and privacy terms, and one-time-code sign-in rather than a reusable TiVaMo password. Administrative access is restricted to authorized staff through company identity controls.
Those controls can add a step, but each is intended to reduce a specific risk.
The safest place for data you don't need is nowhere
Modern systems make it easy to collect more data than is needed. Our approach is to limit collection and retention where practical and to give the data we keep a defined purpose. Data minimization does not mean that no technical metadata is ever processed; it means avoiding collection or retention that does not serve an operational, security, legal or product need.
IP addresses are a good example. TiVaMo does not make a visitor's IP address part of the financial profile we build for a customer, and our marketing lead records do not store a raw IP address as a lead attribute. IP addresses are, however, processed or retained in some operational contexts, including security and fraud prevention, onboarding and legal-acceptance records, audit logging, contact-form handling and infrastructure logs. Service providers we use can also process IP addresses as part of providing their services.
Where sensitive data is retained, we use a combination of encryption provided by our cloud and database platforms and, for selected fields, application-level encryption. In some matching and lookup cases, we use keyed cryptographic hashes so a system can compare values without keeping the original value in searchable form.
Keeping private systems private
The same general approach runs through the infrastructure underneath TiVaMo today.
Separate environments. Production, development, marketing and analytics are deployed in separate cloud environments. This limits how far a problem in one can spread and helps us apply access controls by function.
Private databases. Our primary application and marketing databases use private networking rather than being directly exposed to the public internet. Public-facing services sit behind edge security controls.
Administrative access is different. Administrative access is restricted to authorized staff through company identity and access controls, and administrative actions are logged.
Analytics is separated from application workloads. Our analytics environment is separate from the production application environment, and reporting uses curated datasets rather than treating the live application database as the reporting interface.
Specialists handle specialized functions. Stripe handles payment-card processing and identity-document verification workflows. TiVaMo receives the results and data needed to continue onboarding, but we do not operate our own card-processing or identity-document storage system. We also use established providers for functions such as email delivery and live chat on our marketing site. The specific providers we use may change over time as our needs and the available capabilities evolve.
Short-lived credentials for deployment. Our deployment pipeline uses short-lived cloud credentials rather than permanent keys.
Often a useful security improvement is not another product. It is reducing how many people, systems and data flows need access to the thing being protected.
Built for failure, and honest about it
Good security assumes that things can go wrong. Hardware fails, software has bugs, people make mistakes and credentials are attacked. Our current controls include database backups and recovery capabilities, system logging and monitoring, and security reviews of access and configuration.
We are also building and documenting the controls expected of a more mature security program, with SOC 2 readiness in mind. That work is ongoing. TiVaMo does not treat a future audit or certification as a substitute for day-to-day security practices, and we do not claim an attestation that has not been completed.
There are things I will not claim. I will not say TiVaMo is unhackable, because no system is. I will not say that encryption, a firewall or a certificate makes risk disappear. Security is risk management: reducing exposure, limiting the impact of mistakes, detecting problems and recovering effectively.
TiVaMo will continue to change, and our security controls will change with it. This is a description of the platform as it exists today, not a claim that every control we may want in the future is already in place. The principles remain straightforward:
Collect and retain data for a defined reason.
Keep private systems private where their function allows.
Limit access and verify important actions.
Maintain the ability to recover from failures.
Accept some friction when removing it would also remove a meaningful protection.
Trust is hard to earn and easy to lose. For a company like TiVaMo, protecting it is not only a technology concern. It is part of how the product is designed and operated.