Cybersecurity and Application Security

The question a board has to be able to answer

Sooner or later a board member asks whether the institution is secure. The answers usually available are that we think so, that our supplier says so, or that nothing has happened yet. The third is the most common and the least useful. It is a statement about luck.

The question no longer comes only from inside. Banking in Tanzania is supervised by the Bank of Tanzania, and a supervised institution is expected to hold a view of its own operational risk. Partners ask before they will connect: a mobile money operator, an aggregator, a fintech that wants to sit behind your licence, a corporate customer whose auditors want to know where its payroll data sits. Often it arrives as a questionnaire with a deadline, and the institution that cannot answer loses the business.

Exposure grew because the business grew. Institutions across the region moved onto phones, agents and wallets quickly and for good reasons, and each addition widened what they answer for. Deposits are confidence, and in a market where news travels through the same networks your customers bank on, one publicised incident costs more than it touched. A bank has a supervisor and a name built over decades. A SACCO or a microfinance institution has often digitised fast with no security function of its own. A telco or a fintech is the platform, with no branch network to fall back on.

Security decided with the scope, not after it

Security raised at the end of a project is a commercial problem before it is a technical one. A serious finding a week before launch offers three answers and all of them cost: move the date, go live carrying a risk nobody priced, or spend money not in the budget. Institutions under pressure take whichever hurts least that week, and live with it for years.

So security requirements belong in the scope conversation, settled with your risk and compliance people and priced alongside everything else. That does not make findings disappear, and a supplier who promises it will is telling you something about themselves. What changes is when you learn about a problem, what answering it costs, and who owns it. A gate at the end belongs to whoever holds it. Scope belongs to the people already accountable for the rest of the work.

What an independent assessment is worth

The people who build software should not be the only people who examine it. An independent assessment, commissioned by you and reported to you, is how a risk committee gets more than assurance from the party being assured about. Whether you appoint the assessor or we engage one on your instruction, the report is yours.

A finding is not a verdict. It is an item with a severity, an owner, a cost and a date. What matters is the decision it forces. Fix it now and move the launch. Fix it inside the plan. Fix it later and record why. Or accept it, in which case someone with the authority to accept risk for the institution puts their name to that. The last is a board decision rather than an engineering one. An institution that can show how each finding was answered stands better with a supervisor than one holding a clean report and no account of how it got there. An assessment also describes one moment, so assurance is a running cost rather than a project line.

We design and build to the requirements your institution is subject to and to the standards your risk function adopts. We do not hold certifications on your behalf, and we will not tell you that our involvement makes you compliant with anything. Where you want to be measured against a recognised standard, that assessment belongs to an accredited assessor and the decision to seek it is yours.

The software you did not write

Most institutions run far more software they bought than software they asked for. A core banking system from one supplier, channels bought from several over the years, an aggregator in the middle of payments, packages for accounting and human resources, and whatever a business unit signed up to on a card last quarter. Every one brings somebody else's weaknesses inside your institution, and your supervisor and your customers draw no distinction between a weakness you created and one you inherited.

You answer for software you did not write and cannot see. What you can control is the contract. A right to assess, or to have an assessment done on your behalf. An obligation to tell you when they have a problem that touches you, rather than when it reaches the news. A commitment to fix, with the seriousness of the problem setting the urgency. Those terms cost almost nothing before signature and are close to impossible afterwards. A supplier who refuses all of them has answered the question you were asking.

Supplier assurance is a programme rather than an event, and it needs an owner. The common gap is not the supplier nobody checked. It is the supplier checked once, four years ago, by someone who has since left.

Incident readiness is a business plan

The question that follows whether you are secure is what happens when you are not. That plan is not a technical document. Almost every decision in the first hours is commercial, legal or reputational. Who has the authority to take a channel offline on a Saturday night, knowing what a weekend without it costs. Who decides that customers must be told. Who signs what is said to them.

Communications decide most of the reputational outcome. Customers need to hear it from you, in Kiswahili as well as English, before they hear a version somewhere else. Branch staff and the contact centre have to be able to answer before the first customer asks. Silence reads as concealment, and whatever fills it will not be your account of events.

Notification is its own decision and it is a legal one. Banking is supervised by the Bank of Tanzania, and Tanzania has a Personal Data Protection Act. An incident touching customer information or a supervised service carries obligations, and establishing what they require of you is work for your legal counsel and compliance function to complete in advance. The middle of an incident is the most expensive place to start reading the law.

Then rehearse it, with the people who would genuinely be in the room: the chief executive, legal, communications, operations, the chair of the board risk committee. The useful result is rarely a better document. It is discovering that three people each assumed someone else could authorise the decision.

Working with us

We start with discovery: what you run today, what your contracts with existing suppliers permit, what your risk function requires, and where your real exposure sits rather than where it is comfortable to look. The scope and plan that come out of it are yours whether or not we go on to build anything.

Through delivery you see working software in an environment you control, open to your own engineers or an independent reviewer while the work is happening, not at handover. Source code and documentation are yours from the first commit. We support what we build, train your people, and expect you to be able to leave. There is no lock-in, in the contract as well as in the code.